Consultative Committee for Space Data Systems

The Consultative Committee for Space Data Systems (CCSDS) was formed in 1982 by the major space agencies of the world to provide a forum for discussion of common problems in the development and operation of space data systems. The Committee meets periodically to address data systems problems that are common to all participants, and to formulate sound technical solutions to these problems.^[1] It is currently composed of eleven member agencies, 22 observer agencies, and over 100 industrial associates.

Since its establishment, it has been actively developing Recommended Standards for data- and information-systems standards to

1. reduce the cost to the various agencies of performing common data functions by eliminating unjustified project-unique design and development, and
2. promote interoperability and cross support among cooperating space agencies to reduce operations costs by sharing facilities.

Member agencies

There are eleven space agencies with full voting membership in the CCSDS. At the CCSDS' bi-annual meetings, the week-long working committee meetings are followed by a general meeting where the member agencies vote to approve the committees' recommendations and direct the other business of the organization.^[2] These agencies and the nations they represent are:

• Brazil - Instituto Nacional de Pesquisas Espaciais (INPE)
• Canada - Canadian Space Agency (CSA)
• China - China National Space Administration (CNSA)
• European Union - European Space Agency (ESA)
• France - Centre National d'Etudes Spatiales (CNES)
• Germany - Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
• Italy - Agenzia Spaziale Italiana (ASI)
• Japan - Japan Aerospace Exploration Agency (JAXA)
• Russia - Russian Federal Space Agency (RFSA)
• United Kingdom - UK Space Agency (UKSA)
• United States of America - National Aeronautics and Space Administration (NASA)

^[3]

General Recommendations

The CCSDS develops recommendations, called Blue Books, for standards in order to:

• Reduce the cost of performing space missions
• Enable cross support for space missions
• Improve understanding of space related data
• Preserve archived space related data

Report types

• Blue: Recommended Standards
• Magenta: Recommended Practices
• Green: Informational Reports
• Orange: Experimental or ongoing research
• Yellow: Record, but not Historical
• Silver: Historical

Specific Recommendations

The CCSDS recommends for Spacecraft to Earth communications the

• avoidance of or the turning off of the 'randomizer', as the CCSDS currently recommends a randomizer similar to the BBC NICAM randomizer
• avoidance of transmission downlink waveforms with very poor Doppler performance, like FM
• avoidance of error correction systems with weaker performance than the Voyager Program code—a (7, 1/2) convolutional code concatenated with (255,223) Reed-Solomon code (typically with 3-bit quantization)
  • A rate 1/2, constraint length 7 convolutional code with Viterbi (maximum likelihood) decoding is already a standard for both NASA and ESA. It has been used in several missions and has demonstrated the expected coding gain.
• use of wavelet encoding of images using ICER or JPEG2000, as opposed to JPEG
• use of separate Packet and Frame sizes to increase error correction margin in the space channel
• avoidance of the False Sync Problem : Issue 1 of the Telemetry Channel Coding Blue Book (May 1984) made reference to a "False Sync" problem in footnote 5. As defined by the Recommendation at that time, the codeblock "attached sync marker" was included as a part of the Reed-Solomon data space. Various solutions were studied and it was finally decided to adopt the simplest technical solution: to remove the attached sync marker from the encoding process.

False Sync snafu

The Telemetry Channel Coding Blue Book (May 1984) made reference to a "False Sync" problem. It was discovered that under certain repeating data values (like test patterns of "01010101...") the then CCSDS "attached sync marker" encoding algorithm regenerates the pattern of the leading data bytes within in the leading bytes of the check symbol field—a place where they should not be.

If the leading bytes happen to be the codeblock sync marker, two sync markers will appear in each R-S codeblock, leading to confusion in determining which is the correct starting point for the codeblock. The Recommendation indicated that a solution would need to be found.

Various solutions were studied and it was finally decided to adopt the cleanest technical solution: to remove the attached sync marker from the encoding process.

In addition, by steering the 32-bit sync marker away from the R-S encoder, the R-S codeblock now has space for an additional 32 bits of data. This solution was incorporated into Issue 2, References which redefined the "Codeblock" (and "Transfer Frame", for consistency) to exclude their respective "attached sync markers". Of course, an attached sync marker must still precede each uncoded Transfer Frame, or each R-S codeblock.

Benefits of CCSDS

• Promotes understanding of exchanged data
• Reduces nonrecurring costs:
  • Fewer project-specific developments
  • Shorter test times
  • Less training of staff is needed
• Reduces recurring costs:
  • More commercial off-the-shelf (COTS) hardware is needed
  • Fewer facilities because of load leveling
  • Only selected redundancy is needed
  • More automation, less staff
• Mitigates mission risk
• Enables ingest and access data archives

Important CCSDS standards

Related standards

• CCSDS Advanced Orbiting System (AOS)
• CCSDS File Delivery Protocol (CFDP)
• CCSDS Image Compression standard CCSDS 122.0-B-1
• Packet Telemetry
• Producer Archive Interface Methodology Abstract Standard (PAIMAS)
• Proximity-1 Space Link Protocol
• Spacecraft Monitoring & Control (SM&C)
• Space Link Extension Services (SLE)
• Space Communications Protocol Specifications (SCPS)
  • SCPS-FP -- A set of extensions to FTP to make it more bit efficient and to add advanced features such as record update within a file and integrity checking on file transfers.
  • SCPS-TP -- A set of TCP options and sender-side modifications to improve TCP performance in stressed environments including long delays, high bit error rates, and significant asymmetries. The SCPS-TP options are TCP options registered with the Internet Assigned Numbers Authority (IANA) and hence SCPS-TP is compatible with other well-behaved TCP implementations.
  • SCPS-SP -- A security protocol comparable to IPsec
  • SCPS-NP -- A bit-efficient network protocol analogous to but not interoperable with IP
• Telemetry Channel Coding
• XML Telemetric and Command Exchange (XTCE)

Pre-CCSDS standards craft in service

There are a few pre-CCSDS standards craft in active service

• Voyager 1
• Voyager 2

this only means they do not transmit in the standard CCSDS packet formats. These craft do however use CCSDS standardized error correction formats in the downlink segment.

References

• The content of this article was adapted and expanded from the www.ccsds.org (public domain)

1. ^ "Consultative Committee for Space Data Systems recommendation for space data system standards: Time code formats". NASA. NASA Technical Reports Server. http://hdl.handle.net/2060/19890006406. Retrieved 27 September 2011. 
2. ^ Established Space Communications Standards Organization CCSDS Gets a Makeover, published 2001-03-05, accessed 2009-11-08
3. ^ CCSDS.org - Member Agencies accessed 2009-11-08

External links

NSSDC (NASA)

• CCSDS Official Web Site URL accessed 13 March 2006
• CCSDS Documents in PDF format URL accessed 12 April 2006
• An Introduction to CCSDS URL accessed 12 April 2006
• CDSCC, an acronym sometimes confused with CCSDS URL accessed 12 March 2006
• Goddard Space Flight Center URL accessed 12 March 2006
• NASA Jet Propulsion Laboratory
• National Space Science Data Center (NSSDC) at the NASA Goddard Space Flight Center URL accessed 12 March 2006