CCSDS Tutorial CESG – CCSDS Engineering Steering Board 8th April 2014.

CCSDS Tutorial CESG – CCSDS Engineering Steering Board 8th April 2014

CCSDS Organization Interrelationships Benefits and drivers
Agenda The Essential Message CCSDS Overview CCSDS Organization Interrelationships Benefits and drivers Future Mission drivers CCSDS Areas SEA Area P. Shames NASA/JPL MOIMS Area N. Peccia ESA/HSO-GI CSS Area E. Barkley NASA/JPL SOIS Area C. Taylor ESA/TEC-ED SLS Area G. P. Calzolari ESA/HSO-OS SIS Area K. Scott Mitre, USA MO Services SM&C WG M. Merri ESA/HSO-GD

through the international standardization process
The Essential Message CCSDS: Advancing Technology through the international standardization process What could be more important? Right now, between major human spaceflight and robotic programs, it is critically important to prepare for the upcoming international missions. History shows that waiting until the program starts is too late to develop effective and capable cross-support technology. New missions are bringing new communication needs; new technology is becoming available; therefore the standardization process is more important than ever There are resource issues but CCSDS is re-prioritizing and delaying some schedules in order to deal with those issues. Verbally: upcoming missions will be a challenge for CCSDS and will need prioritization. Will not speak of “increasing” or “decreasing” resources.

CCSDS Overview CCSDS = The Consultative Committee for Space Data Systems For international collaboration in spaceflight, the most critical enabling technology is communications and data systems. The domain of CCSDS is interoperability and cross support for comm/data systems Interoperability translates to: Operations -- flexibility, capability and access to additional resources Development - reduced risk, development time and project costs For government, industry, agencies, vendors, programs and projects CCSDS focus is multi-agency missions, but standards also bring the same benefit to a single-agency with multiple contractors CCSDS Started in 1982 developing at the lower layers of the protocol stack. The CCSDS scope has grown to cover standards throughout the ISO communications stack, plus other Data Systems areas (architecture, archive, security, XML exchange formats, etc.

CCSDS Overview - Participation
CCSDS – An Agency-Led International Committee Currently 11 Member agencies Currently 29 Observer Agencies Agencies represent 27 nations (plus European orgs) Currently 151 Commercial Associates ~ attendees at Spring/Fall meetings Also functions as an ISO Subcommittee TC20/SC13 - Space Data & Info Transfer Systems Represents 20 nations OBSERVER AGENCIES ASA/Austria BFSPO/Belgium CAS/China CAST/China CLTC/China CSIR/South Africa CSIRO/Australia DCTA/Brazil DNSC/Denmark EUMETSAT/Europe EUTELSAT/Europe GISTDA/Thailand HNSC/Greece IKI/Russia ISRO/India KARI/Korea KFKI/Hungary MOC/Israel NCST/USA NICT/Japan NOAA/USA NSARK/Kazakhstan NSPO/Taiwan SSC/Sweden SSO/Switzerland SUPARCO/Pakistan TsNIIMash/Russia TUBITAK/Turkey USGS/USA MEMBER ASI/Italy CNES/France CNSA/China CSA/Canada DLR/Germany ESA/Europe FSA/Russia INPE/Brazil JAXA/Japan NASA/USA UKSA/UK e 5

CCSDS Overview Adoption by Missions
Verbalize that 148 publications were used for some time in the last 31 years

SISG IOP Some Organizational Interrelationships
IOP: Interoperability Plenary – highest level interagency agreements on space interoperability IOP IOAG provides to CCSDS the IOAG priorities and guidance for future communications/operations plans CCSDS: provides open international standards for space mission interoperability IOAG: Interagency Operations Advisory Group interoperable mission support infrastructure (Comm & Nav only) SFCG: Space Frequency coordination Group: space agency spectrum management forum Close Coordination for Internetworking CCSDS participant inputs bring in needs of individual organizations SISG IOAG SISG: Space Internet Strategy Group – New Int’l agreements for Internetworking (ISO Layer 3) in Space CCSDS participant inputs (plus observers)

CCSDS Structure and Organization
Systems Engineering Stakeholders Missions / Programs Liaisons Infrastructure providers CCSDS CCSDS Secretariat Space Assigned Numbers Authority CCSDS Management Council (CMC) CCSDS Engineering Steering Group WG’s Spacecraft Onboard Interface Services Space Link Services Cross Support Services Space Internetworking Services Mission Ops & Info Mgt Services

CCSDS Relationships with ISO
Technical Committee 20 (ISO/TC20): Aircraft and Space Vehicles Other TCs Other SCs (Secretariat: AIAA) Subcommittee 14 (ISO/TC20/SC14): Space Systems and Operations Missions / Programs TC20/SC13 Heads of Delegation (CCSDS CMC) Subcommittee 13 (ISO/TC20/SC13): Space Data and Information Transfer Systems (Secretariat: NASA) CCSDS CCSDS Secretariat Space Assigned Numbers Authority CCSDS Management Council (CMC) ISO CCSDS Management Council (CMC) CCSDS Engineering Steering Group CCSDS Engineering Steering Group Design Engineering & Production Interfaces, Integration & Test Environment (natural & induced) Materials and Processes Operations & Ground Support Program Management Space Debris Systems Engineering Space Link Services Space Internetworking Services WG’s Spacecraft Onboard Interface Services Cross Support Services Mission Ops & Info Mgt Services CCSDS

Some Organizational Interrelationships
OMG: Object Management Group Industry standards for exchange of application information among vendor products CCSDS/OMG have some common standards and periodic joint meetings IETF: Internet Engineering Task Force IRTF: Internet Research Task Force Open international standards for IP suite and DTN CCSDS uses such industry standards as a basis, whenever possible ECSS: European Consortium for Space Standards - European regional standards for space mission support CCSDS/ECSS coordinate on compatible standards AIAA: American Institute of Aeronautics and Astronautics North American regional standards for space mission support Regional Standards coordination, and AIAA provides Secretariat support for CCSDS, ISO TC20/SC13 and SC14

Standards Benefits and its Usage
Cross-support & Interoperability Multi-agency support agreements Multi-mission support arrangements Reduce costs Shared (expensive, scarce) resources S/W and H/W reuse Commercial implementations Increase reliability / reduce risks Systems developed in the Standards Bodies have broader review and external input, hence more capable/reliable Where Standards are currently used Space to Ground (and Space) Standards Physical (RF), Modulation & Coding, Link, File delivery Network (in development) Spacecraft On-Board I/F Services (in dev) Ground to Ground Standards Service Management Space Link Extension (SLE) and Cross Support Transfer Services (CSTS) interfaces MO Services (in development) End to End Configurations Standard “ABA” configurations Advanced Solar System Internetworking (SSI) Secure communications approaches “end to end” Sub-bullet to be clarified verbally for ABA SSI will be covered in later presentation

CCSDS Development Cycle
“end to end” Sub-bullet to be clarified verbally for ABA SSI will be covered in later presentation !!! 2 Independent Prototypes !!!!

CCSDS Overview

Future Mission Drivers
PAST PRESENT DRIVERS FOR THE FUTURE In Situ Exploration Human Expeditions Long Duration, High Reliability Mobile comm protocols Voice, Video, Medical handling Onboard Autonomy Highly integrated ops International Space Station Adv. Orbital Sys (AOS) Early DTN Prototyping Shuttle/SpaceLab CCSDS packets Asteroid/Surface Exploration Autonomy, High bandwidth Multi-Agency Mission Ops Complex Deep Space Missions Human or robotic exploration Longer Duration Mobile comm protocols Fully automated routing Network-Managed DTN Optical Communications Complex human or robotic Scenarios for remote surface missions Fully automated Space Internetworking Brief Recon Flyby, Short-Lived Probes Direct-to-Earth links Missions designed for orbital relays, Longer duration Orbital Remote Sensing Long Duration, high bandwidth High Spatial, Spectral, & Temporal Resolution Low Latency Comm Complex link topologies SensorWebs for synchronized remote sensing Verbally go over this slide quickly Single-Spacecraft Survey/Sensors Spacecraft Constellations and formation flying Multi-Discipline and Multi-Resource SensorWebs Next Generation Observatories More Capability Multiple Spacecraft drive network needs Even Greater Capacities require new coding schemes Located Even Farther from Earth Single-Spacecraft Observatories in LEO Greater Distances Higher bandwidth Next Generation Observatory Complexes

The CCSDS Plan for the Future
CCSDS Strategic Plan The CCSDS Plan for the Future Systems Engineering: Cross-cutting functions and architecture-wide integration Towards standardized Mission Operations Services at Application Level on Ground and On-Board including a complete Navigation Message Standardization Towards an extensible Space Communications Cross Support Service Management and Transfer Services (Cross Support of Communications Assets) Towards onboard Standardized avionics architectures; wireless communications and software defined radios Towards an unified Space Data Link Protocol, optical links, new sync and channel coding schemes and compression Towards standardized Space System Internetworking Services and the Solar System Internet (SSI)

SEA: cross cutting topics & architectures

System Engineering Area (SEA)
Objective Guide overall CCSDS architecture for space mission communications, operations, and cross-support Support the CESG in evaluating consistency of all area programs of work with the defined architecture Create cross-cutting working groups and BOFs as required to progress the work of CCSDS Focus Define reference architectures for describing space mission communications, operations, and cross-support standardization Coordinate and collaborate with other areas about architectural choices and options Define standards for cross cutting topics such as security and discrete architecture frameworks, and for those that cross cut multiple areas or layers of protocols Support other working groups and BoFs that are addressing cross cutting issues SEA Current and Recent Working Groups CCSDS Reference Architecture (RASDS) and Information Architecture (RASIM) Security Working Group Delta-DOR Working Group Timeline Data Exchange Birds of a Feather XML Standards and Guidelines (XSG) Special Interest Group Space Assigned Numbers Authority (SANA) Steering Group (operational) 17

Reference Architecture for Space Data Systems (RASDS)
From Space Communication Cross Support Architecture (SCCS-ADD) Uses RASDS to describe cross support system architectures Enterprise, Service, Component, Protocol and End-to-End Views, recommended deployments

Information Reference Architecture
From Reference Architecture for Space Information Management (RASIM) Concepts and terminology for space information management architectures Terminology, methods, and abstract information service objects

Security WG Overview From Security Architecture Security is everywhere
Sec WG provides specific guidance to many other groups

Delta-Differential One-way Ranging
From Delta-DOR Green Book Delta-DOR is a high resolution, plane of sky, ranging and position technique Based on VLBI, uses two or more ground stations and a quasar reference source

Timeline Data Exchange – Concept Model
Uses Fact Based Modeling (FBM) – S. Valera From TDE BoF Concept Paper Describes a definitive model of timeline data exchange concepts For inclusion in proposed working group

Space Assigned Numbers Authority (SANA)
From operational SANA web site On-line registry of CCSDS special objects and identifiers To be accessible via HTTP/REST interface

CCSDS Overview

Distributable Mission Operations Functions
What Do we Want to Achieve? Prepare for the future Future missions will be more complex and require more collaboration across organisation Better interoperability between systems (e.g. X monitoring its lander via Y’s orbiter, Z submitting planning requests for its payload on W’s S/C, …) Scalability Expandable systems Difficult to predict now what will be needed tomorrow Protect from technology evolution Replace implementation technology without major system redesign Reduce cost (i.e. schedule, risks, …) of [On-board and Ground-based] system development Facilitate availability of generic software infrastructure Facilitate availability of new, state-of-the-art, plug-in [commercial] components Re-use components (including legacy systems) … and mission operations Re-use operational concepts across missions Increase operational commonality across components (less training costs)

Telerobotics End-to-End Model
What Do we Want to Achieve? Prepare for the future Future missions will be more complex and require more collaboration across organisation Better interoperability between systems (e.g. X monitoring its lander via Y’s orbiter, Z submitting planning requests for its payload on W’s S/C, …) Scalability Expandable systems Difficult to predict now what will be needed tomorrow Protect from technology evolution Replace implementation technology without major system redesign Reduce cost (i.e. schedule, risks, …) of [On-board and Ground-based] system development Facilitate availability of generic software infrastructure Facilitate availability of new, state-of-the-art, plug-in [commercial] components Re-use components (including legacy systems) … and mission operations Re-use operational concepts across missions Increase operational commonality across components (less training costs)

The Navigation Roadmap

Archival Standards

Cross Support Services (CSS) Area within CCSDS

Cross Support Architecture Overview
Enterprise Views Service Views

Cross Support Architecture Overview
Communication Views Current Status: Description Document available on the CCSDS Website G-1 Magenta Book in progress – normative requirements on putting various CCSDS documents/recommended standards together to achieve cross support Anticipate agency review this Fall

Great, But…. Several SLE transfer services  several separate recommendations, prototyping, sets of agency reviews, maintenance issues, etc Recommendations tended to be duplicative in terms of substantial technical content CCSDS should be able to do something better… Define an approach that factors all of the common technical stuff into a re-usable framework and re-use framework to meet agency needs for inter-operation, data transfer, including data that does not necessarily have a spacelink component E.g, what about ground station service production monitor data?

SLE Success Story (2002 to 2009) Svalbard Tromsø Kiruna ESOC Redu Saskatoon Roskosmos Neustrelitz St. Hubert Weilheim Denver CNES/ Toulouse DLR/GSOC Goddard Madrid/CEB/VIL CNSA Usuda JAXA Goldstone Whitesands JPL Xi'an Ibaraki Maspalomas Uchinoura Huston Bangalore ISRO Kourou Malinidi This slide shows the widespread adoption of SLE, leading to successful cross-support. Santiago Hartebeestoek New Norcia Perth Canberra O'Higgins Kerguelen SLE Service Provider SLE Service User Troll

CSTS builds on SLE success (1)
SLE and CSTS are similar; they both transfer data between a Provider (typically a ground station) and a User (typically a mission control center). However, the types of data that can be transferred with CSTS are different than for SLE. At this time, the services being developed are restricted to the ‘return’ of data (i.e. data flows from the Provider to the User). However, there is nothing preventing the development of services in which the data flow is from the User to the Provider.

CSTS builds on SLE success (2)
A substantial part of the software source code that implements SLE can be reused for CSTS.

CSTS adds new services efficiently
The CSTS Framework provides a reusable foundation that allows services to be defined and implemented efficiently. CSTS 1 CSTS L service CSTS Specification Framework PRC 1 PRC 2 PRC M procedure OP 1 Operations provide the most basic capabilities – e.g. “transfer these bytes”. Procedures build on the capabilities provided by operations. To ensure that they are generally useful, procedures are purposely abstract. They typically define mechanisms (e.g. for buffering and releasing data) but do not specify the type of data being carried. (The services that use a procedure make the abstract parts concrete) The combination of the procedures and operations is known as the Framework. The Framework is specified once, and can then be referenced from multiple service specifications. This allows the service specifications to be quite small – the normative section of the Monitored Data Service is only 6 pages long! Similarly, the Framework can be implemented once, and that implementation can be reused across all the CSTS services. Said another way: the reusable Framework allows new services to be defined and implemented efficiently. OP 2 OP 3 OP 4 OP N operation

Services use the Framework
The Monitored-Data service allows the User to monitor the overall status of service being provided by, say, a ground station for a particular pass. Monitoring is accomplished via periodic reports and/or specific queries, plus the User is notified when “events of interest” occur. As always, the Association-Control procedure establishes a connection between the User and Provider. The Cyclic-Report procedure allows the User to request (and receive) periodic status reports. The Information-Query procedure allows the User to request (and receive) a single status report. The Notification procedure is used to notify the User when an “event of interest” occurs. Note that there are other Framework procedures, but they are not needed to accomplish the Monitored-Data service.

…But it all needs to be managed…
Real-world spacecraft tracking requires planning and coordination of many different types of information ranging from spacecraft telecommunications capabilities, to trajectory data, to real-time service execution control to accounting for services rendered.

Service Management: A Brief Overview
Objective Define management service standards cross support management of Telemetry, Command, Ranging and future CCSDS inter-agency services Space Element MDOS SCCS Complex Service Mgmt Interface Utilization Data Transfer Interface (Spacelink) Complex Management Management Internal Management Internal Space Link Services Transfer Management (Transfer Service Production) Service Provision Frames Service Data Transfer Interfaces (Terrestrial) Provider RF and Modulation Equipment Transfer CLTU Service Service Users Provider

Service Management Lifecycle

Current CCSDS Service Management Projects
Service Catalog – definition of how to state characteristics of TTC Services offered; telemetry services supported at S, X bands up to 50 Mbps, with LDPC coding Planning Information – definition of planning information such as predicted communication geometry – first draft this Fall Schedule of Services – definition of data format for publication of network schedules -- Agency Review imminent Configuration/Service Agreement information – definition of space link, terrestrial data transfer (i.e. SLE and CSTS), and levels of services to be provided (for example number of spacecraft contacts for a given period of time) Service request/service package – definition of a request for TTC network services and response for such a request Event Sequence – Definition of how spacecraft, especially those in deep space, may change the configuration such that the ground systems can respond properly when it is impossible to convey the changes in real time (i.e. preplanning required because of long light time delays) Service Accounting – definition of accounting for services and qualities of services rendered; e.g, 1.2 million telemetry frames returned; 99% successful decoding

SOIS – Spacecraft Onboard Interfaces Services

Current Working Groups
Application Support Services WG Wireless WG Subnetwork Services WG (Currently Inactive) The SOIS area covers onboard communication services with the intention of standardising H/W and S/W interfaces between avionics elements & devices. Wireless activities cover intra-spacecraft communication, AIV and RFID Our work is aligned with the European SAVOIR initiative and the WG includes representatives from the US SUMO initiative 44 44 44

Background The SOIS WG was established in an attempt to improve the ease of connectivity and reuse of onboard hardware and software (based on a comparison with terrestrial networks where everything connects to everything – TCP/IP protocol stack, Wireless, standard APIs) The initial strategy included the development of a single transport protocol that could be used by all missions but it was quickly realized that this was a step to far A rethink resulted in the following approach: Develop a layered communications architecture Define a set of subnetwork communication services Align datalink protocols to the defined set of services Define a common set of application related services Encourage the take up by primes and equipment suppliers Work on wireless standard were a more recent addition to the group and are mainly targeted at AIV and human spaceflight 45 45 45

CCSDS SOIS Reference Communications Architecture
46 46 46

CCSDS SOIS - Development Process
International CCSDS SOIS Working group US developments SUMO TRP and GSTP activities CORDET SAFI IMA …. Savoir CCSDS Recommendations PUS CAN Milbus SpaceWire Driving inputs for ECSS Subnet and PUS standards Adopted by ESA under ECSS 47 47 47

Wireless The wireless working group has so far concentrated on analyzing terrestrial technology for use in space and in AIT A CCSDS Green book provides an excellent overview of this work and two magenta books are available on the application for low rate technology and the use of RFID for inventory management The work has now shifted to defining a standard RFID tag encoding and the application of high rate wireless technology The group has also cooperated in defining a common test-bed for assessing technology 48 48 48

High Data-Rate Communication and Sensing Examples

SOIS – Related Developments
Current Embedded as part of the Savoir avionics architecture Used to drive ECSS protocol development (harmonizing Milbus, Can-Bus and SpaceWire) Applicable in the new PUS update Compatible with the emerging Mission operation service (MOS) SOIS file and packet store in combination CFDP for ESA Missions (Euclid, JUICE) GSTP evaluation by primes (Atrium, TAS and OHB) Additional R&D activities planned Future Continue to promote the benefits of a layered architecture and standard I/Fs (Missions and R&D activities) Re-assessment after evaluation from primes and consolidation of SUMO/SAVOIR architecture 50 50 50

Summary Nothing is perfect and we are aware that not all our activities are perfectly aligned yet – this is understandable as the unbelievers need time to see the light! Probably the biggest contribution of the SOIS work is that the space avionics community is beginning to acknowledge the benefits of a layered communication architecture and the use of standardized interfaces 51 51 51

SLS – We are the Space Link Services

Communications Scenario

Layering (1) CCSDS started from this layered approach.
The CCSDS Data Link Layer and the Physical Layer are hosting the typical Tracking, Telemetry and Command functions; i.e. they are the historical and basic layers for CCSDS Communications.

SLS Area in the CCSDS Layered approach (simplified view)

The Basic Communications Standards: Physical Layer
The Radio Frequency and Modulation Systems standard collects most of the standards for the physical layer. It focuses upon the standardization of RF and modulation systems for Earth stations and spacecraft. Technical Recommendations are subdivided into groups representing the various subsystems. These are: Earth-to-Space Radio Frequency, Telecommand, Space-to-Earth Radio Frequency, Telemetry, Radio Metric, and Spacecraft. Policy Recommendations include: Frequency Utilization, Power Limitations, Modulation Methods, Operational Procedures, Testing Recommendations, and Spacecraft Systems. Other standards for the physical layer include Pseudo-Noise (PN) Ranging Systems and Data Transmission and PN Ranging for 2 GHz CDMA Link via Data Relay Satellite and Proximity-1.

There is also a coding standard for Proximity-1.
The Basic Communications Standards Synchronization and Coding (sub)layer The standards for the Synchronization and Coding (sub)layer do differentiate between Telemetry and Telecommand as they offer different types of services for those two unbalanced channels . The TM Synchronization and Channel Coding standard provides unidirectional (one way) transfer of a sequence of fixed-length TM or AOS Transfer Frames at a constant frame rate over a Physical Channel across a space link, with optional error detection/correction. The TC Synchronization and Channel Coding standard provides unidirectional (one way) transfer of a sequence of variable-length TC Transfer Frames over a Physical Channel across a space link, with optional error detection/correction. While the TC coding scheme is stable since years, many different options with different Frame/Bit Error Rate (FER/BER) performances are available for telemetry; i.e. convolutional, Reed-Solomon, concatenated RS+convolutional, Turbo Codes, Low-density Parity-check (LDPC) codes, Serially Concatenated Convolutional Codes and DVB-S2. There is also a coding standard for Proximity-1.

Coding Gain Here a comparison of the Bit Error Rate curves for different coding schemes allowed by CCSDS. A given coding scheme can be good for a given scenario but cumbersome for another one (like driving to supermarket with a Rolls-Royce  ) Better

The Basic Communications Standards Data Link Protocol (sub)layer
The most important capability of the Space Data Link Protocols (sub)layer is the Master/Virtual Channel multiplexing. The (original) standards also differentiate between Down/Up-link. The TM Space Data Link Protocol standard specifies the Data Link layer protocol, services, and procedures pertaining to the Transfer Frame for the Space-to-Earth link. It replaces the old Packet Telemetry Specification. The TC Space Data Link Protocol standard specifies the Data Link layer protocol, services, and procedures pertaining to the Transfer Frame for the Earth-to-Space link. It replaces the old Packet Telecommand Specification. The Advanced Orbiting Systems, Networks and Data Links: Architectural Specification was developed in the (late) 1980’s to provide bidirectional transmission of multiple data types (including voice and video) at high data rates targeted to manned/man-tended space stations etc. Today largely used by (ESA) EO payloads: The AOS Space Data Link Protocol standard specifies the Data Link layer protocol, services, and procedures pertaining to the CCSDS Version-2 Transfer Frame. There is also a Proximity-1 Space Data Link Protocol.

CCSDS Space Packet Protocol
Historically, the Space Packet Protocol (SPP) has been the only method providing a flexible structure (of top of Space Data Link protocols) for transferring user/application data from Space to Earth or vice versa. Used as a common structure for TM and TC. Most innovative feature (in the early 1980s) was the APID which identified the packet contents. Previously, content was identified by data position in a repetitive frame. The APID set the data content free from the clockwork frame. Packet header also contains fields for multiplexing packets in to the link. APID subsequently (AOS and pre-Internet) proposed for reuse as networking identifier for packet routing. CCSDS packet is going to be “superseded” as network protocol with the increased networking by IP (and eventually DTN) over Encapsulation Service.

On top of the Data Link Layer… and below
For many years, the Space Packet has been used as the main tool to carry data for whatever application including images as well as house keeping data etc. Eventually a new structure, called Encapsulation Packet, has been added to carry data in a more flexible manner as e.g. for the transfer of IP Protocol Data Units (PDUs) via CCSDS Space Data Link Layer protocols. Finally, also the basic layers for CCSDS Communications are subject to evolution and - together with new features as e.g. new powerful Uplink Codes, Variable/Adaptive Coding Modulation (VCM/ACM), enhanced space data link protocol(s). Very important is the seamless introduction of Optical Communications that aim to highly improve the Space Link Services. The related WG has just been created and will deal with Optical Coding & Modulation as well as with supporting services (e.g. weather data, etc.).

Last but not least: Data Compression and Security (1 of 2)
On-board data compression is needed to make full use of limited spacecraft resources like data storage and downlink capacity. The Multispectral Hyperspectral Data Compression WG takes care of this subject. They started their work with the “Lossless Data Compression” standard and eventually added standards for “Image Data Compression” and “Lossless Multispectral & Hyperspectral Image Compression” In fact multispectral & hyperspectral images can occupy enormous data volumes, and so compression algorithms specifically designed to exploit the three-dimensional structure of such images can provide tremendous benefit to space missions.

Last but not least: Data Compression and Security (2 of 2)
The Space Data Link Layer Security Working Group (SLS-SEA-DLS) is a joint activity between SLS and SEA Areas. The objectives of this Working Group is to develop a recommendation for a security protocol operating at the data link layer of CCSDS space links. Target missions are civilian missions (science, earth observation, telecommunications, ...). This security protocol provides authentication and/or encryption both for uplink and downlink. It is compatible with CCSDS TM, TC and AOS data link protocols and independent from any specific cryptographic algorithm. This security protocol is a function within the Data Link Protocol (sub)layer.

SIS: We’re the End-to-End Internetwork (Purple Stuff)

Space Internetworking Systems Area
The objective of the Space Internetworking Services (SIS) Area is to address the communications services and protocols supporting end-to-end communications among applications, particularly where those communications may span multiple heterogeneous physical and data link technologies. Areas addressed by SIS include the networking infrastructure to support application-to-application communication onboard a single spacecraft, communications among multiple spacecraft, and communications between space-based applications and their counterparts on Earth and/or other planetary bodies. The SIS Area deals with communication services and protocols that are independent of specific link technology (as a lower layer bound) and independent of application-specific semantics (as an upper bound). Thus the SIS area covers essentially the network through application layers of the OSI reference model. SIS protocols use the underlying communication and infrastructure services provided by the Space Link Services (SLS) and Spacecraft Onboard Interface Services (SOIS) areas and any other onboard networks, and provide the networked connectivity needed by applications developed in other CCSDS areas such as Mission Operations and Information Management Services (MOIMS) and Spacecraft Onboard Interface Services (SOIS). The SIS services provide hardware-independent mechanisms for identifying end systems, and provide communications services that allow users to disregard whether the communication is over a single data link layer or over multiple hops. The suite of capabilities developed by the SIS Area accommodates all ranges of delay, interactivity, and directionality, although not all protocols are appropriate for all environments. The services provided by SIS protocols free applications from having to have intimate knowledge of the underlying communications protocols and mechanisms, and from having to know the physical location(s) of the entities with which they are communicating. This enables applications to focus on the application-specific protocols and interactions necessary to achieve their goals.

SIS Area Relation to OSI Layers
SIS is primarily concerned with the network and transport layers of the OSI model. SIS occasionally addresses applications designed to run over a network (e.g. CFDP).

Why Internetworking? Lots of different physical layer technologies
Each designed / tuned for its particular local environment Different data link addressing mechanisms Lots of different applications Internetwork layer provides: End-to-End delivery of datagrams Applications don’t have to care where their peer are (same processor, link- local, or 10 hops away) – just need to know their Network Address ‘Global’ addressing mechanism (e.g. IP addresses) Network

Internetworking and The Solar System Internet (SSI)
Internet Protocol suite (TCP/IP suite) works well in some space environments but not all: IP suite assumes low-delay, constant connectivity Delay / Disruption Tolerant Networking (DTN) suite designed to work in space environments where IP suite doesn’t: DTN routers can hold on to messages until an outbound link becomes available, e.g. DTN can run as an internetwork directly over links (right side of figure) or on top of another suite (e.g. TCP/IP) (left side of figure)

The Current SIS Portfolio

SIS Working Groups Motion Imagery and Applications Voice
Interoperable (space-to-space and space-to-ground) video based on industry standard codecs Voice Interoperable (space-to-space and space-to-ground) voice based on industry standard codecs Delay / Disruption Tolerant Networking End-to-end internetworking for the space environment CFDP Revisions Updates to the CFDP specification to better support operation over a network layer; larger file sizes, etc.

CCSDS MO Services Smart Services for Mission Operations

All in One Slide The Problem The Solution
Terrestrial software has developed enormously in the last 2 decades whereas the Ground-OBSW interface has not In Europe the ECSS PUS continues to serve us well, but: Only used in Europe Only really extends as far as the edge of the MCS Fixed to CCSDS Space Packets Interoperability between organisations is still difficult No standardised set of interfaces for common operations No standardised definition of what information is exchanged Everyone does this differently The Solution CCSDS is defining MO Services that are: Distributable Designed to be used on-ground, on-board and across the spacelink Extend from on-board, through the ground systems, to the end users Independent of transport and encoding technology Compatible with all CCSDS Agencies

Phone Services Music Services Car Cockpit Place call Receive call
Show contacts … Music Services Stream songs Listen music library By song By author By album

What Can We Learn From This Analogy?
Communication is an enabling technology Necessary condition (must have it) … but the real breakthrough is in the definition of semantically rich application-level services Are independent of the communication technology (Bluetooth, wire/USB, …) Allow independent developments at the two ends of the interface Any Bluetooth telephone works with any Bluetooth-enabled car stereo Does not prevent innovation Increase the availability of commercial solutions → boost competition → cost reduction Increase long term maintainability You can replace the phone w/o replacing the car!

How Does This Apply to Space?
Mission Product Distribution On-board Schedule Handling Services TM/TC Processing Mission Planning Flight Dynamics Automation MO Service Framework

What Are MO Services? Coherent set of application-level services needed to operate a space mission, such as: Classical Monitoring & Control (TM, TC, Events) Navigation (e.g. orbit, attitude, events) Mission planning, scheduling and automation Mission product data distribution File management Time management Software management … and more (extensible) Key technical proprieties of MO Services: Follow SOA approach Standardise exchange of semantically rich data Are defined in a common way (MO Service Framework) Are technology and location independent Are compatible with model driven development and auto-coding

MO Services at Work (an over simplified deployment example)
Spacecraft (ESA) Rover (NASA) M&C Services File Management Service … M&C Services Planning Services Navigation Services … Scientific Community Mission Control Centre (ESA) Payload Control Centre (NASA) Data Distribution Services Planning Services … M&C Service Data Distribution Services Planning Services … M&C Services SW Management Service … Mission Operations are achieved by orchestrating a number of distributed functions in order to achieve the desired results. In the most simple configuration, a space mission consists of a Spacecraft and a Mission Control Centre <CLICK>In the classical configuration, the functions for operating the spacecraft reside in the Mission Control Centre and they typically include <READ LIST> <CLICK>Of course, some of these functions must interact with their counterpart on-board to properly functions. For instance, the M&C function receives HK TM from the S/C and send TC to the S/C, Mission data handling function needs payload data that are collected on-board and on-board SW may be managed via dump and upload of new SW patches. <CLICK>In the future, with the advent of more advance technology and more challenging missions, some functions that traditionally reside on the ground will migrate on-board. For instance, for deep space missions will more and more need planning/scheduling/automation function on-board, or missions carrying location devices such as GPS will be able to estimate Flight Dynamics information such as their orbits. These functions would also automatically extend to landers in case of more complex missions. <4 CLICKS>Similarly, some of these functions are also used in other parts of the ground segment, for instance by the S/C Manufacturer, by the Payload/Science Teams, by the Payload Data Centre and by the Scientific community. For instance, the Mission Control Centre may act as a provider of HK TM in pretty much the same manner as it acts as consumer of HK TM from the S/C. <CLICK>The SM&C WG has recognised that these interfaces are common to most missions and has devised a number of Mission Operations services that need standardisation. As also shown in the picture, these services goes across organisation and system boundaries and as such require to be specified in a way that is not bound to a particular technology, maybe used only by a single organisation. Additionally, most organisation do have already systems that perform many of these functions and therefore it is necessary to identify means to be able to re-use these systems. Finally, I would like to point out that all the proposed services are application-level services, i.e. the information that is transferred between provider and consumer contains the semantic of the service. To operate a mission it is not enough to enable the communication between elements. Spacecraft Manufacturer (Astrium) Re-use of same MO Services over different technologies! Standardisation of MO Services across space and ground segments!

Benefits of MO Services
Higher re-use and lower cost: Reuse across missions of components (ground/on-board) code (Open Source Code already available) ops concept (even from different Primes), people (minimal training) → shorter schedules, less risks, higher quality … Ability to establish common multi-mission infrastructure (ground/on-board) Availability of commercial components increased industrial competition ability to select the best product from a range of compatible components vendor independence Higher flexibility: More interoperability between agencies (10 agencies today involved in MO) Flexible deployment boundaries (ground/on-board) Capability of “bridging” between technologies Improved long-term maintainability (both for components and infrastructure) Higher Mission Data Return: Increased mission automation and specialisation by service orchestration Focus resources on field-specific innovation (not in reinventing the I/Fs)

MO Services are Getting Real!
Because they are being used more and more! CCSDS Prototypes CCSDS requires that each new standard is validated via 2 independently- developed and interoperable prototypes Test Bed available that simplifies this work and might also be used in the future to “certify” compliant MO applications So far 3 space agencies (CNES, DLR, ESA) are involved in formal prototyping Other Prototypes/ Studies Since 2006, about 29 (known) prototypes: Astrium-D -> 1 CNES -> 6 DLR -> 1 ESA -> 4 EUMETSAT -> 1 NASA/GSFC -> 2 NASA/KSC -> 1 NASA/JPL -> 2 NASA/JSC -> 7 NASA/MSFC -> 2 UKSA -> 2 Several studies A number of Ph.D.’s Actual Projects ISIS: CNES new ground segment infrastructure (fully MO based internally) EGS-CC: new European Ground System Common Core (external I/F) METERON: ISS experiment (MO over DTN) OPS-SAT: ESOC cube-sat (space-ground link fully MO based)

MO Services Roadmap

Do We Really Need MO Services?
Of course not, we could live without them, but …

Antique car have a charm,
does this applies also to old spacecraft and ground systems?

Back-up Slides Back-up SLIDES

Security WG Systems Engineering Area - Security
Goals: Develop security overview & threat assessment, and security architecture, framework and related standards Current focus (algorithms, key management, network layer security, threat/risk) Working Group Products: Cryptographic Algorithms BB, Security Architecture MB, Security Glossary GB, threat assessment and security guidelines have been published. Algorithm Green Book ready for publication. Key Management MB with normative procedures and abstractions, the Space Data Link Security (SDLS) is an application of this in a Blue Book. Updating Threat Assessment Green Book to include improved guidance for system designers. Planning development of authentication and access control baseline recommendation for services and other protocols

Systems Engineering Area – Delta Differential One-way Ranging
Delta-DOR WG Goals: Develop Delta Differential One-way Ranging (Delta-DOR) service High resolution plane of sky position estimation using VLBI techniques Develop integrated service, interoperability points (interfaces) and related standards Working Group Products: Delta-DOR Raw Data Exchange Format (RDEF) Blue Book, Delta-DOR Green Book, and Delta-DOR Operations Magenta Book published. Planning an update of Delta-DOR RF signal structures to improve positional accuracy, working with RF&Mod WG to finalize these. Developing a new Quasar Catalogue Magenta Book, procedures, validation & registry operations Revising Delta-DOR Operations MB with new service request and quantitative criteria Planning new Delta-DOR implementation architecture MB Considering new Delta-DOR Service Request to configure and coordinate observatins at multiple ground stations Four agencies (NASA, ESA, JAXA, China) already have operational Delta-DOR services, others are planning to develop them. 87 87

Systems Engineering Area – Timeline Data Exchange
Timeline Data Exchange BoF Goals of Spring Technical Meeting: Review, discuss, and finalize Charter Review and discuss 2014 Spring SpaceOps paper Collaborate on a draft of the WG Concept Paper Discuss Timeline Data Exchange Concept with other working groups Birds-of-a-Feather (BoF) Status: The job of a BoF is to propose work to develop a new set of standards and describe these in a Charter (work plan of how they expect to operate) and a Concept Paper (what they propose to create) This is also a discussion of how CCSDS “makes sausage” Draft Charter was reviewed, discussed, and edited Draft of the Concept Paper was produced Based on a concept first presented at Space Ops 2012 Included an information modelling session (expertly facilitated by S. Valera) resulting in a formal model of the concepts Model and descriptive statements will be integrated with the paper to form the WG Concept Paper Met with with Service Management and SM&C WGs Strong SM support for use of Activity, Event, Measurement Timelines “Active” discussion with SM&C; expressed concern that TDE overlaps SM&C MO/MAL/Common 88 88

Systems Engineering Area Report – XML Standards & Guidelines
XML Standards & Guidelines SIG Goals: Create CCSDS standards and guidelines for the creation and use of XML Schema Relevant for work in other WGs (CSS/SM, MOIMS/SM&C, Nav, DAI, SOIS/ASS) Develop agreed standards for CCSDS namespace and use, XML content, management and versioning policies, and eventually, XML style & schema construction Special Interest Group (SIG) Products: XML schema are used in Nav, SM, SM&C, SOIS XTEDS, DAI, RAC, but CCSDS does not yet have cross cutting standards This is a “shoemaker’s children” type problem CCSDS namespace RFC, an approach to namespace use and versioning, is ready CCSDS XML policy and SANA registry management YB, is agreed in SIG Schema shall be fully qualified, but that unqualified versions shall be able to be exported Schema namespace must indicate version for major changes, needs a fuller discussion and analysis Future work on XML construction guidelines and common terminology / ontology requires affected WGs, SM&C, SM, Nav, SOIS, DAI, RAC, to provide experts to work as part of SIG to create acceptable approaches 89 89

SANA Operations & SANA Steering Group (SSG)
Systems Engineering Area Report – Space Assigned Numbers Authority SANA Operations & SANA Steering Group (SSG) Goals: Operate the Space Assigned Numbers Authority (SANA) Create a registry framework for CCSDS “magic numbers” and operations Support CCSDS WG use of the registry functions Operations Status: SANA and web site operational, thirty-two (32) approved registries, seven (7) candidate registries not yet approved, most waiting on final Blue Book publication. Registries include: CCSDS abbreviations and glossary, Spacecraft Identifiers, protocol identifiers & mapping codes, XML schema, CCSDS object identifiers, and other data types SANA is now official CCSDS SCID MACAO, and agency rep registry, handles all assignments. All relevant publications have been updated to reflect change. Propose production RESTful programmatic interface for all SANA registries Changes to SANA and SSG presence on CCSDS web site have been initiated. CCSDS Organization and Processes YB is also being updated accordingly. 90 90

MO Services Status MO Services Framework is available (ESA + CNES)
Standards are published (MAL and COM) Java implementation available as Open Source Software from ESA and CNES C++ draft implementation available as OSS from NASA/JSC Language mappings Java API is published (CNES) C++ API in draft format (NASA) Technology (encoding and transport) mappings CCSDS Space Packet under finalisation (CNES + DLR) Ground-to-Ground under selection MO Services M&C Service under final review (RIDs due 31May14) (ESA + DLR) Common Services under finalisation (ESA + CNES) Mission Planning Service may be next … inputs from the stakeholder community are welcome Check out:

Packet (CCSDS or Encapsulation) Packet Multiplexing in TM and AOS
Link Structure TM or AOS link consists of a stream of fixed length frames Each frame contains synchronisation, header, data (e.g. CCSDS packets) and error correction coding Any frame may be allocated to a particular Virtual Channel (VC). VCs are used share the link efficiently VC1 Frame VC2 Frame VC3 Frame VC1 Frame VC3 Frame VC2 Frame VC2 Frame VC1 Frame VC2 Frame VC1 Frame VC3 Frame VC3 Frame Packet Multiplexing Frame N in Virtual Channel Frame N+1 in Virtual Channel Fixed Length Frame Variable Length Packet Frame Header End of Packet Packet Packet Beginning of Packet Frame Header End of CCSDS Packet CCSDS Packet Fill Packet First Header Pointer in Frame Header points to First Packet header in frame Packet length in Packet Header points to next packet header in frame Packets which overrun the frame end are continued into the next frame in the VC and rejoined when demultiplexed Fill packets are used to complete a frame when a new packet is not available to complete it Minimum fill CCSDS packet size is 7 bytes. Incomplete minimum fill packets run into next frame Packet Segmentation Fixed Length Frame Frame Header End of CCSDS Packet Beginning of long CCSDS Packet Frame Header Continuation of CCSDS Packet Frame Header End of long CCSDS Packet Beginning of CCSDS Packet First Header Pointer in Frame Header points to First Packet header in frame Packet length in Packet Header points out of frame and used to check length of reassembled packet First header pointer set to 2043d to indicate no packet header in frame First header pointer points to end of the long packet and beginning of the next packet

The Avionics Reference Architecture
OBT Mgmt P/L Manager System mode mgmt Power Plan/ Autonomy Framework Thermal AOCS Applications SSMM Mgmt Satellite Conf and Eqpt Mgmt System FDIR Component services On-board time =SOIS TAS Abstract component services Container services RTOS Connector services Communication services addressing physical distribution across nodes = SOIS MTS PUS specific PUS Context Mgmt Avionics Equipment virtual devices =SOIS DVS PUS monitoring OBCP interpreter SOIS Subnetwork layer (1553, CAN, SpW) (including HDSW) CPU EEPROM Boot PROM RAM SGM UART SpW CAN MIL-1553 OBTimer HW watchdog Software bus SOIS Layers File/ Compress/ Encrypt Solid State Mass Memory Security Unit Telemetry Telecommand Payload Computer Space Linux Application Payloads & Instruments Sensors & actuators Computation microcontroller Digital Sensorbus ADCs / DACs Remote Terminal Unit Remote Interface Unit Libraries: mathematical, etc. Standardized devices Legacy devices Onboard Communications H/W (e.g. MIL-STD-1553B, SpaceWire, CAN RS422) Application software Execution platform On board computer Hardware Intelligent Buses Hardware functions BSP

Space Universal Modular Architecture (SUMO)
March 2014 Space Universal Modular Architecture (SUMO) Industry Consensus Interoperability Standards

Motion Imagery and Applications
Identify and agree upon use of existing digital video standards and interfaces to provide common interoperability of video systems between spacecraft and from spacecraft to ground-based operations centers Status Completed Agency Reviews of Red Book. Currently documenting proof of interoperability based mostly on use of standards in use by industry and used on the ISS Next Steps Considering standardizing an implementation of bundle streaming services for video operations Spatial and Temporal motion imagery requirements Specifically out of scope in the book is ground-to-ground video sharing.

Voice Voice and audio communications provides recommendations for interoperability between space agencies Voice is considered mission critical for human space missions. Due the international cooperation in space mission it is mandatory that different space agencies can easily communicate between each other on the ground, to the spacecraft and with astronauts, taiconauts and cosmonauts in the spacecraft or during an EVA as well. Voice is also used for Satellite mission for communications with Ground Antennas and Space agencies. Status: Finishing Blue book for Voice an Audio communications. Preparing test to transfer Voice and Audio via DTN protocol. Next steps: Interoperability testing for Blue book generation. Prepare work for new digital voice matrixes. Prepare work for Audio communication for missions beyond the Moon. Old TDM technology going out, moving to digital (voice matrix will be all-digital mixer)

Delay / Disruption Tolerant Networking (DTN)
DTN provides ‘Internet-like’ services for the space environment DTN enables automated data handling: configure the network (provide connectivity, schedules, etc.) and then let the network automatically deliver data to the destinations Status: About to go to 3rd round of CCSDS Agency reviews on the Bundle Protocol and Licklider Transmission Protocol (LTP is a reliable data link mechanism for use ‘under’ BP) Deploying on ISS for use by payloads and operations (file transfer) Next steps: (DTN) Network Management, Security, Routing Under ‘configure the network’ be sure to mention that this includes allowing mission managers to ‘keep DTN in its box’ – i.e. DTN will do what it can with whatever resources it’s given, but doesn’t assume it’s given all of a particular link / pass, etc. Network Management here refers to managing the DTN (BP) portion of the network; it doesn’t include trying to get in CSS’s business. DTN will take as inputs the outputs (schedules, etc.) from e.g. CSS-SM.

CFDP Revisions CCSDS File Delivery Protocol (CFDP) is a protocol for automatic file transfer over space links, which may be characterized by long signal propagation delay and/or lengthy service outages. CFDP was standardized in CCSDS procedures require that standards be periodically reviewed and modified as necessary, or retired if no longer needed; this review is now under way for CFDP. Several enhancements to CFDP have been requested: End-to-end file delivery notification (“Finished” PDU) for files sent in Unacknowledged Mode to support CFDP over network (e.g. CFDP over BP) Option to send limited metadata with each individual file data PDU (to make individual PDUs more useful) Option to send files larger than 4 Gigabytes. Status: Consensus reached on Blue Book changes. Next steps: Agency review of the revised CFDP Blue Book. Plan for retrofitting implementations and testing interoperability. Blue Book: need resolution on checksum issue, need pics pro-forma

CCSDS Tutorial CESG – CCSDS Engineering Steering Board 8th April 2014.

Similar presentations

Presentation on theme: "CCSDS Tutorial CESG – CCSDS Engineering Steering Board 8th April 2014."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CCSDS Tutorial CESG – CCSDS Engineering Steering Board 8th April 2014.

Similar presentations

Presentation on theme: "CCSDS Tutorial CESG – CCSDS Engineering Steering Board 8th April 2014."— Presentation transcript:

Similar presentations

About project

Feedback