Results for “CCSDS data standards” — Page 3

NASA NTRS2007

Standardizing Navigation Data: A Status Update

This paper presents the work of the Navigation Working Group of the Consultative Committee for Space Data Systems (CCSDS) on development of standards addressing the transfer of orbit, attitude and tracking data for space objects. Much progress has been made since the initial presentation of the standards in 2004, including the progression of the orbit data standard to an accepted standard, and the near completion of the attitude and tracking data standards. The orbit, attitude and tracking standards attempt to address predominant parameterizations for their respective data, and create a message format that enables communication of the data across space agencies and other entities. The messages detailed in each standard are built upon a keyword = value paradigm, where a fixed list of keywords is provided in the standard where users specify information about their data, and also use keywords to encapsulate their data. The paper presents a primer on the CCSDS standardization process to put in context the state of the message standards, and the parameterizations supported in each standard, then shows examples of these standards for orbit, attitude and tracking data. Finalization of the standards is expected by the end of calendar year 2007.

VanEepoel, John M.↗

NASA NTRSDate not supplied

The State of Cryptolib – The Open-Source Satellite Cryptography Library

What state would the world be in if all internet traffic was unencrypted? Imagine an alternate universe where you can plug a packet sniffing device into your home internet and capture the web traffic of the entire world. It seems obvious that this scenario is less than desirable. If we would not allow this for the internet, why would we allow this in the space domain? With the advent of open-source ground stations, commercial off the shelf hardware, and ground stations as a service, the barrier to entry for space communications is rapidly lowering. New players enter the space realm everydayevery day, and the presence of tools to allow apprentice evildoers the ability to exploit satellite communications is on the horizon. Not only are legacy missions at risk, but future missions are as well - particularly lower budget science missions with more stringent sciencesize, weight, and power constraints. that may find it difficult to utilize hardware-based encryption solutions. In terms of Civilian Aerospace, NASA Standard 1006 generally directs that missions "shall protect the command stack with encryption that meets or exceeds Federal Information Processing Standards (FIPS) 140". Fortunately, the Consultative Committee for Space Data Systems (CCSDS) has published an international standard on Space Data Link Security. The combination of these two forces has resulted in CryptoLib - an open-source, C-based, encryption library that aims to be CCSDS SDLS compliant. CryptoLib is designed to support smaller missions on a tight budget that may be subject to the more stringent command link encryption requirements. Additionally, CryptoLib serves as an underpinning in JPL's Key Management & Cryptography (KMC) suite and is also designed to function as a 'drop-in' for smaller missions. CryptoLib is in active development and currently provides Telecommand (TC), Telemetry (TM), and Advanced Orbiting Systems (AOS) encryption and decryption capabilities with a variety of encryption and authentication schemes. This presentation will report the latest features, current status, and future plans for CryptoLib.

open-source encryption↗

NASA NTRSDate not supplied

The State of CryptoLib – The Open-Source Satellite Cryptography Library

What state would the world be in if all internet traffic was unencrypted? Imagine an alternate universe where you can plug a packet sniffing device into your home internet and capture the web traffic of the entire world. It seems obvious that this scenario is less than desirable. If we would not allow this for the internet, why would we allow this in the space domain? With the advent of open-source ground stations, commercial off the shelf hardware, and ground stations as a service, the barrier to entry for space communications is rapidly lowering. New players enter the space realm everydayevery day, and the presence of tools to allow apprentice evildoers the ability to exploit satellite communications is on the horizon. Not only are legacy missions at risk, but future missions are as well - particularly lower budget science missions with more stringent sciencesize, weight, and power constraints. that may find it difficult to utilize hardware-based encryption solutions. In terms of Civilian Aerospace, NASA Standard 1006 generally directs that missions "shall protect the command stack with encryption that meets or exceeds Federal Information Processing Standards (FIPS) 140". Fortunately, the Consultative Committee for Space Data Systems (CCSDS) has published an international standard on Space Data Link Security. The combination of these two forces has resulted in CryptoLib - an open-source, C-based, encryption library that aims to be CCSDS SDLS compliant. CryptoLib is designed to support smaller missions on a tight budget that may be subject to the more stringent command link encryption requirements. Additionally, CryptoLib serves as an underpinning in JPL's Key Management & Cryptography (KMC) suite and is also designed to function as a 'drop-in' for smaller missions. CryptoLib is in active development and currently provides Telecommand (TC), Telemetry (TM), and Advanced Orbiting Systems (AOS) encryption and decryption capabilities with a variety of encryption and authentication schemes. This presentation will report the latest features, current status, and future plans for CryptoLib.

open-source encryption↗

NASA NTRS1994

The ESA standard for telemetry and telecommand packet utilisation: PUS

ESA has developed standards for packet telemetry and telecommand, which are derived from the recommendations of the Inter-Agency Consultative Committee for Space Data Systems (CCSDS). These standards are now mandatory for future ESA programs as well as for many programs currently under development. However, while these packet standards address the end-to-end transfer of telemetry and telecommand data between applications on the ground and Application Processes on-board, they leave open the internal structure or content of the packets. This paper presents the ESA Packet Utilization Standard (PUS) which addresses this very subject and, as such, serves to extend and complement the ESA packet standards. The goal of the PUS is to be applicable to future ESA missions in all application areas (Telecommunications, Science, Earth Resources, microgravity, etc.). The production of the PUS falls under the responsibility of the ESA Committee for Operations and EGSE Standards (COES).

Kaufeler, Jean-Francois↗

NASA NTRSDate not supplied

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

NASA NTRSDate not supplied

NASA Delay Tolerant Networks: Operational, Evolving, an Ready for Expansion

The future of humanity’s presence beyond Earth depends on the successful commercialization of space. For commercialization to succeed, companies need cost-efficient architectures to support their business models and minimize risks for human capital, design, development, and operations. An ongoing challenge to any space enterprise is the reality that terrestrial network technologies are insufficient to provide reliable communications between assets in space. Whether you need to ensure your valuable data is safely transmitted to the ground or reliably delivered between platforms in orbit, ensuring data integrity over intermittent communication links is a necessity. Current solutions to space communications rely heavily on manual recording, storing, and retrieval of data from spacecraft. The current standard in space communication protocols, Consultative Committee for Space Data Systems (CCSDS) Space Packet standard, is reliant on inflexible network architectures based around mission-critical infrastructure to ensure data delivery. However, by automating the recording, storing, retrieval, and verification of data with Delay Tolerant Networks (DTN), the operator is freed from the dependence on manual data management and expensive mission critical infrastructure. NASA has been developing delay tolerant systems since the late 1990’s. Multiple DTN implementations have been established during that time, each suited to different use cases. Most notably, the DTN deployment for the International Space Station (ISS) includes demonstration of two DTN technologies: Interplanetary Overlay Network (ION) and Delay Tolerant Network Marshall Enterprise (DTNME). Beyond ISS, there are even more NASA DTN deployments being considered. Now that DTN implementations are maturing, it is appropriate to reflect upon these decades of work, review the integration and performance of the existing ISS deployment, and explore the future possibilities for DTN deployment industry-wide. The ISS DTN deployment is a complex architecture consisting of different DTN implementations for the onboard and ground network environments. The ION DTN implementation is being used in the on-board network. The Huntsville Operations Support Center (HOSC) DTN implementation, DTNME, is used by the ground network supporting ISS and will soon be a second onboard gateway too. The two implementations work cooperatively to provide high fidelity data services to flight operations users and payload developers across the globe. Though the two implementations yield a quality service, limitations are evident. Data rate, data storage, and device management are constrained by the services themselves and the complex nature of the deployment. Evolution of operations concepts will improve system capabilities and stability, but significant improvement will require additional development to the implementations themselves and to the overall deployment architecture. Taking advantage of the ongoing development and operation of the ISS DTN service will be central to the success of the future evolutions of NASA DTN deployments while demonstrating the benefits of DTN’s low-cost reliable data communication protocols for the growing commercial space industry. A broad effort on DTN integration and support is necessary to promote expansion beyond existing applications. NASA is developing several useful DTN implementations across a number of different systems: ION, DTNME, High-Rate DTN (HDTN), Bundle Protocol Library (BPLib), and others. To prevent fragmentation, DTN implementation teams need to communicate, collaborate, and integrate with one another to build a solid operational foundation for new DTN deployments. The establishment of a group that can assist new DTN users with understanding the purpose of each DTN implementation, provide best practices, and serve as a general knowledge base is paramount. Potential use of DTN on Gateway and other future NASA missions further drives the need for streamlined communication between DTN implementation teams. A well-integrated and highly engaged NASA DTN working group should help provide system architects the best DTN solutions for future commercial space efforts. This paper will first review the history of DTN implementations, explore the shortcoming of current space networking solutions given available limits in technology, and therefore establish the need for Delay Tolerant Networking in space communications. Secondly, the authors will explore NASA’s array of DTN implementations and highlight their usefulness to space applications. Thirdly, this paper will establish general DTN implementation distinguishing factors. Fourthly, the authors will discuss attempts to create a generic DTN comparison matrix, and the authors will review potential future topics in DTN innovation and collaboration, highlighting several key future efforts. Finally, this paper will describe how the institution of a NASA DTN Working Group will benefit DTN adoption across the governmental and commercial space sector. The goal of this paper is to encourage enthusiasm for DTN, share strategies for improving DTN on both current and future applications, promote the collaboration of DTN implementation groups within the international space operations community, and open the conversations about DTN, priorities, complexities, and innovation to the wider spaceflight industry.

DTN↗

NASA NTRS1998

An Object-Oriented Interface to the CCSDS Ground Telecommand Services

The Telecommand Data Routing and Channel Services defined by the Consultative Committee for Space Data Systems (CCSDS) are flexible enough to support a myriad of commanding models. Because the standard is so broad, the traditional approach has been to implement only the portion of the standard needed by the particular spacecraft being tested/operated. Tasked with providing Telecommand Services for an entire class of spacecraft, where each spacecraft may choose any valid CCSDS commanding model, NASA Code 584 designed a common architecture capable of handling the full CCSDS protocol. The solution uses another CCSDS standard - the Standard Formatted Data Unit (SFDU) as the interface to the Telecommand Services. SFDUs provide a consistent way of labelling data objects, as well as allowing data objects to encapsulate other data objects. The resulting interface is: - Flexible: The full Data Routing and Channel Services are available via a single interface. The client (i.e. the command source) may enter commands at any layer within the protocol stack, specify any of the data aggregation or segmentation methods, and dynamically set any configuration parameter defined in the standard. - Object-oriented: Each object specifies both the data and the actions to be performed with the data. An object may contain other objects. - Expandable: New capabilities are added by defining new objects. Objects pass thru the protocol layers until they reach the applicable layer. The resulting design is: - Modular: The logic for each protocol layer is contained in a separate Application Program Interface (API). The objects used for the external interface are also used for communication between layers. - Distributable: The design can be split along any layer boundary for distribution across multiple machines. The objects ensure data consistency across platforms. This paper describes the SFDU-based interface and the resulting protocol implementation. The implementation is currently used by NASA (National Aeronautics and Space Administration) for integration & test of the microwave Anisotropy Probe (MAP) and Earth observer-I (EO-l) spacecraft. It will be used for post-launch operations of these spacecraft as well as the Imager for Magnetopause to Aurora Global Exploration (IMAGE) spacecraft.

Ray, Timothy Joseph↗

NASA NTRS1985

Standards for space data systems

NASA has chaired the Consultative Committee for Space Data Systems (CCSDS) for the past four years. During that time, a top-level, end-to-end reference model for space data sytems has been developed that identifies the functions anad services which must be provided by space data systems, and defines the interfaces between major functional elements. A group of definitions for standard protocols has been derived by analyzing these interfaces, and a set of detailed guidelines for space data system standards is in the final stages of negotiation among member CCSDS agencies. Two guidelines that address packet telemetry and channel coding have been approved and are being incorporated into the internal standards of member agencies. Others (packet telecommand, time code, standards data format unit) are in review within CCSDS technical panels and will soon be submitted for approval. These guidelines provide a mechanism for significant cost savings in the implementation of space data systems by allowing reuse of hardware and software for different payloads and for missions, and by enabling the substitution of new technology/higher performance elements at key points in the data system without causing major perturbations in the remainder of the system.

Connell, E. B.↗

NASA NTRS2000

The Role of Standards in Modern Military and Civilian Telemetering Applications

This paper describes the role of standardization in the implementation of modern telemetry communications systems.

standards telemetering CCSDS data exchange facilit↗

NASA NTRS1990

CCSDS - An approach to the definition of common standards for space data and information systems

The Consultative Committee for Space Data Systems (CCSDS) was formed in 1982 to develop common space system data structures, protocols, and interfaces which would facilitate mutual international support and interoperability. It soon emerged that CCSDS's activities exerted synergistic forces on systems development efforts. Currently, CCSDS is composed of both member-status and observer-status agencies; while only one member agency is admitted from any one country, multiple additional agencies may participate as observers. CCSDS recommendations to date have identified a common architectural approach for the handling and processing of space data.

Greene, Edward P.↗

NASA NTRS2003

Reliable Transport over SpaceWire for James Webb Space Telescope (JWST) Focal Plane Electronics (FPE) Network

NASA's James Webb Space Telescope (JWST) faces difficult technical and budgetary challenges to overcome before it is scheduled launch in 2010. The Integrated Science Instrument Module (ISIM), shares these challenges. The major challenge addressed in this paper is the data network used to collect, process, compresses and store Infrared data. A total of 114 Mbps of raw information must be collected from 19 sources and delivered to the two redundant data processing units across a twenty meter deployed thermally restricted interface. Further data must be transferred to the solid-state recorder and the spacecraft. The JWST detectors are kept at cryogenic temperatures to obtain the sensitivity necessary to measure faint energy sources. The Focal Plane Electronics (FPE) that sample the detector, generate packets from the samples, and transmit these packets to the processing electronics must dissipate little power in order to help keep the detectors at these cold temperatures. Separating the low powered front-end electronics from the higher-powered processing electronics, and using a simple high-speed protocol to transmit the detector data minimize the power dissipation near the detectors. Low Voltage Differential Signaling (LVDS) drivers were considered an obvious choice for physical layer because of their high speed and low power. The mechanical restriction on the number cables across the thermal interface force the Image packets to be concentrated upon two high-speed links. These links connect the many image packet sources, Focal Plane Electronics (FPE), located near the cryogenic detectors to the processing electronics on the spacecraft structure. From 12 to 10,000 seconds of raw data are processed to make up an image, various algorithms integrate the pixel data Loss of commands to configure the detectors as well as the loss of science data itself may cause inefficiency in the use of the telescope that are unacceptable given the high cost of the observatory. This combination of requirements necessitates a redundant, fault tolerant, high- speed, low mass, low power network with a low Bit error Rate(1E-9- 1E-12). The ISIM systems team performed many studies of the various network architectures that meeting these requirements. The architecture selected uses the Spacewire protocol, with the addition of a new transport and network layer added to implement end-to-end reliable transport. The network and reliable transport mechanism must be implemented in hardware because of the high average information rate and the restriction on the ability of the detectors to buffer data due to power and size restrictions. This network and transport mechanism was designed to be compatible with existing Spacewire links and routers so that existing equipment and designs may be leveraged upon. The transport layer specification is being coordinated with European Space Agency (ESA), Spacewire Working Group and the Consultative Committee for Space Data System (CCSDS) PlK Standard Onboard Interface (SOIF) panel, with the intent of developing a standard for reliable transport for Spacewire. Changes to the protocol presented are likely since negotiations are ongoing with these groups. A block of RTL VHDL that implements a multi-port Spacewire router with an external user interface will be developed and integrated with an existing Spacewire Link design. The external user interface will be the local interface that sources and sinks packets onto and off of the network (Figure 3). The external user interface implements the network and transport layer and handles acknowledgements and re-tries of packets for reliable transport over the network. Because the design is written in RTL, it may be ported to any technology but will initially be targeted to the new Actel Accelerator series (AX) part. Each link will run at 160 Mbps and the power will be about 0.165 Watt per link worst case in the Actel AX.

Rakow, Glenn↗

NASA NTRS2006

Simulation Modeling and Performance Evaluation of Space Networks

In space exploration missions, the coordinated use of spacecraft as communication relays increases the efficiency of the endeavors. To conduct trade-off studies of the performance and resource usage of different communication protocols and network designs, JPL designed a comprehensive extendable tool, the Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE). The design and development of MACHETE began in 2000 and is constantly evolving. Currently, MACHETE contains Consultative Committee for Space Data Systems (CCSDS) protocol standards such as Proximity-1, Advanced Orbiting Systems (AOS), Packet Telemetry/Telecommand, Space Communications Protocol Specification (SCPS), and the CCSDS File Delivery Protocol (CFDP). MACHETE uses the Aerospace Corporation s Satellite Orbital Analysis Program (SOAP) to generate the orbital geometry information and contact opportunities. Matlab scripts provide the link characteristics. At the core of MACHETE is a discrete event simulator, QualNet. Delay Tolerant Networking (DTN) is an end-to-end architecture providing communication in and/or through highly stressed networking environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, the DTN protocols reside at the application layer of the constituent internets, forming a store-and-forward overlay network. The key capabilities of the bundling protocols include custody-based reliability, ability to cope with intermittent connectivity, ability to take advantage of scheduled and opportunistic connectivity, and late binding of names to addresses. In this presentation, we report on the addition of MACHETE models needed to support DTN, namely: the Bundle Protocol (BP) model. To illustrate the use of MACHETE with the additional DTN model, we provide an example simulation to benchmark its performance. We demonstrate the use of the DTN protocol and discuss statistics gathered concerning the total time needed to simulate numerous bundle transmissions

network protocols↗

NASA NTRS2010

CCSDS - Advancing Spaceflight Technology for International Collaboration

The Consultative Committee for Space Data Systems (CCSDS) has been developing data and communications standards since 1982, with the objective of providing interoperability for enabling international collaboration for spaceflight missions. As data and communications technology has advanced, CCSDS has progressed to capitalize on existing products when available and suitable for spaceflight, and to develop innovative new approaches when available products fail. The current scope of the CCSDS architecture spans the end-to-end data architecture of a spaceflight mission, with ongoing efforts to develop and standardize cutting-edge technology. This manuscript describes the overall architecture, the position of CCSDS in the standards and international mission community, and some CCSDS processes. It then highlights in detail several of the most interesting and critical technical areas in work right now, and how they support collaborative missions. Special topics include: Delay/Disruption Tolerant Networking (DTN), Asynchronous Message Service (AMS), Multispectral/Hyperspectral Data Compression (MHDC), Coding and Synchronization, Onboard Wireless, Spacecraft Monitor and Control, Navigation, Security, and Time Synchronization/Correlation. Broad international participation in development of CCSDS standards is encouraged.

Kearney, Mike↗

NASA NTRS2017

An Update on the CCSDS Optical Communications Working Group

International space agencies around the world are currently developing optical communication systems for Near Earth and Deep Space applications for both robotic and human rated spacecraft. These applications include both links between spacecraft and links between spacecraft and ground. The Interagency Operation Advisory Group (IOAG) has stated that there is a strong business case for international cross support of spacecraft optical links. It further concluded that in order to enable cross support the links must be standardized. This paper will overview the history and structure of the space communications international standards body, the Consultative Committee for Space Data Systems (CCSDS), that will develop the standards and provide an update on the proceedings of the Optical Communications Working Group within CCSDS. This paper will also describe the set of optical communications standards being developed and outline some of the issues that must be addressed in the next few years. The paper will address in particular the ongoing work on application scenarios for deep space to ground called High Photon Efficiency, for LEO to ground called Low Complexity, for inter-satellite and near Earth to ground called High Data Rate, as well as associated atmospheric measurement techniques and link operations concepts.

Laser and Optical Communications↗

NASA NTRS1988

Data interfaces to the Space Station information system

The general form of the information system to be implemented to provide the broad and flexible services required to support the diverse needs of the U.S. Space Station is discussed. Emphasis is placed on the interfaces to the SSIS (Space Station Information System) and major interfaces within the SSIS. A central theme of the SSIS is the use of international standards, where appropriate and available. These standards include those of the International Organization for Standards (ISO), the Telegraph and Telephone Consultative Committee (CCITT), and the Consultative Committee for Space Data Systems (CCSDS). The specific standards selected or under consideration are enumerated. The effect of the selections on the interfaces visible to users of the SSIS are described, and a status report on the progress of official adoption of the standards is presented.

Carper, Richard↗

NASA NTRS1996

Lossless Coding Standards for Space Data Systems

The International Consultative Committee for Space Data Systems (CCSDS) is preparing to issue its first recommendation for a digital data compression standard. Because the space data systems of primary interest are employed to support scientific investigations requiring accurate representation, this initial standard will be restricted to lossless compression.

digital data compression digital data compression ↗

NASA NTRS1994

Use of data description languages in the interchange of data

The Consultative Committee for Space Data Systems (CCSDS) is developing Standards for the interchange of information between systems, including those operating under different environments. The objective is to perform the interchange automatically, i.e. in a computer interpretable manner. One aspect of the concept developed by CCSDS is the use of a separate data description to specify the data being transferred. Using the description, data can then be automatically parsed by the receiving computer. With a suitably expressive Data Description Language (DDL), data formats of arbitrary complexity can be handled. The advantages of this approach are: (1) that the description need only be written and distributed once to all users, and (2) new software does not need to be written for each new format, provided generic tools are available to support writing and interpretation of descriptions and the associated data instances. Consequently, the effort of 'hard coding' each new format is avoided and problems of integrating multiple implementations of a given format by different users are avoided. The approach is applicable in any context where computer parsable description of data could enhance efficiency (e.g. within a spacecraft control system, a data delivery system or an archive). The CCSDS have identified several candidate DDL's: EAST (Extended Ada Subset), TSDN (Transfer Syntax Data Notation) and MADEL (Modified ASN.1 as a Data Description Language -- a DDL based on the Abstract Syntax Notation One - ASN.1 - specified in the ISO/IEC 8824). This paper concentrates on ESA's development of MADEL. ESA have also developed a 'proof of concept' prototype of the required support tools, implemented on a PC under MS-DOS, which has successfully demonstrated the feasibility of the approach, including the capability within an application of retrieving and displaying particular data elements, given its MADEL description (i.e. a data description written in MADEL). This paper outlines the work done to date and assesses the applicability of this modified ASN.1 as a DDL. The feasibility of the approach is illustrated with several examples.

Pignede, M.↗

NASA NTRS1990

Telemetry and command standards

The first phase of the international Consultative Committee for Space Data Systems (CCSDS) efforts toward the definition of standards for space telemetry, spacecraft tracking, and command functions has established a set of standard space communications techniques capable of satisfying almost the entire spectrum of space mission user requirements. This was achieved by focusing on the distinctive problems associated with the space/ground data link, and developing the infrastructural system designated the 'Open Systems Interconnection'. The intrinsically international coordination by CCSDS of development efforts ensures highly flexible mutual support activities by the various national space agencies.

Hooke, Adrian J.↗