SEARCH · Search NASA

Results for “The Consultative Committee for Space Data Systems (CCSDS)”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 109 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRS1994

Error coding simulations in C

When data is transmitted through a noisy channel, errors are produced within the data rendering it indecipherable. Through the use of error control coding techniques, the bit error rate can be reduced to any desired level without sacrificing the transmission data rate. The Astrionics Laboratory at Marshall Space Flight Center has decided to use a modular, end-to-end telemetry data simulator to simulate the transmission of data from flight to ground and various methods of error control. The simulator includes modules for random data generation, data compression, Consultative Committee for Space Data Systems (CCSDS) transfer frame formation, error correction/detection, error generation and error statistics. The simulator utilizes a concatenated coding scheme which includes CCSDS standard (255,223) Reed-Solomon (RS) code over GF(2(exp 8)) with interleave depth of 5 as the outermost code, (7, 1/2) convolutional code as an inner code and CCSDS recommended (n, n-16) cyclic redundancy check (CRC) code as the innermost code, where n is the number of information bits plus 16 parity bits. The received signal-to-noise for a desired bit error rate is greatly reduced through the use of forward error correction techniques. Even greater coding gain is provided through the use of a concatenated coding scheme. Interleaving/deinterleaving is necessary to randomize burst errors which may appear at the input of the RS decoder. The burst correction capability length is increased in proportion to the interleave depth. The modular nature of the simulator allows for inclusion or exclusion of modules as needed. This paper describes the development and operation of the simulator, the verification of a C-language Reed-Solomon code, and the possibility of using Comdisco SPW(tm) as a tool for determining optimal error control schemes.

Noble, Viveca K.↗

NASA NTRS1996

A space demonstration of the next generation TT and C standards

An initiative to develop an integrated set of space data communication protocols, which will complement and expand upon the current Consultative Committee for Space Data Systems (CCSDS) telemetry and telecommand standards, is reported on. The aim is to provide a comprehensive set of spacecraft control and monitoring data handling services. The space communications protocol standards (SCPS) initiative will provide a set of spacecraft telemetry, telecommand and control (TT and C) standards that will serve a wide range of civilian and military space missions. A software flight test and demonstration of the capabilities of the SCPS protocols was performed using the in orbit space technology research vehicle and compared to laboratory simulations. The results from this test will contribute to the continued SCPS protocol development program.

Shave, N. P.↗

NASA NTRS1999

Flight Dynamics Analysis Branch End of Fiscal Year 1999 Report

This document summarizes the major activities and accomplishments carried out by the Goddard Space Flight Center (GSFC)'s Flight Dynamics Analysis Branch (FDAB), Code 572, in support of flight projects and technology development initiatives in Fiscal Year (FY) 1999. The document is intended to serve as both an introduction to the type of support carried out by the FDAB (Flight Dynamics Analysis Branch), as well as a concise reference summarizing key analysis results and mission experience derived from the various mission support roles assumed over the past year. The major accomplishments in the FDAB in FY99 were: 1) Provided flight dynamics support to the Lunar Prospector and TRIANA missions among a variety of spacecraft missions; 2) Sponsored the Flight Mechanics Symposium; 3) Supported the Consultative Committee for Space Data Systems (CCSDS) workshops; 4) Performed numerous analyses and studies for future missions; 5) Started the Flight Dynamics Analysis Branch Lab for in-house mission analysis and support; and 6) Complied with all requirements in support of GSFC IS09000 certification.

Stengle, Thomas↗

NASA NTRS2001

The Behavior of TCP and Its Extensions in Space

The performance of Transmission Control Protocol (TCP) in space has been examined from the observations of simulation and experimental tests for several years at National Aeronautics and Space Administration (NASA), Department of Defense (DoD) and universities. At New Mexico State University (NMSU), we have been concentrating on studying the performance of two protocol suites: the file transfer protocol (ftp) running over Transmission Control Protocol/Internet Protocol (TCP/IP) stack and the file protocol (fp) running over the Space Communications Protocol Standards (SCPS)-Transport Protocol (TP) developed under the Consultative Committee for Space Data Systems (CCSDS) standards process. SCPS-TP is considered to be TCP's extensions for space communications. This dissertation experimentally studies the behavior of TCP and SCPS-TP by running the protocol suites over both the Space-to-Ground Link Simulator (SGLS) test-bed and realistic satellite link. The study concentrates on comparing protocol behavior by plotting the averaged file transfer times for different experimental configurations and analyzing them using Statistical Analysis System (SAS) based procedures. The effects of different link delays and various Bit-Error-Rates (BERS) on each protocol performance are also studied and linear regression models are built for experiments over SGLS test-bed to reflect the relationships between the file transfer time and various transmission conditions.

Wang, Ruhai↗

NASA NTRS2002

Low Resolution Picture Transmission (LRPT) Demonstration System

Low-Resolution Picture Transmission (LRPT) is a proposed standard for direct broadcast transmission of satellite weather images. This standard is a joint effort by the European Organization for the Exploitation of Meteorological Satellites (EUMETSAT) and the National Oceanic Atmospheric Administration (NOAA). As a digital transmission scheme, its purpose is to replace the current analog Automatic Picture Transmission (APT) system for use in the Meteorological Operational (METOP) satellites. Goddard Space Flight Center has been tasked to build an LRPT Demonstration System (LDS). It's main objective is to develop or demonstrate the feasibility of a low-cost receiver utilizing a Personal Computer (PC) as the primary processing component and determine the performance of the protocol in the simulated Radio Frequency (RF) environment. The approach would consist of two phases. In the phase 1, a Commercial-off-the-Shelf (COTS) Modulator-Demodulator (MODEM) board that would perform RF demodulation would be purchased allowing the Central Processing Unit (CPU) to perform the Consultative Committee for Space Data Systems (CCSDS) protocol processing. Also since the weather images are compressed the PC would perform the decompression. Phase 1 was successfully demonstrated on December 1997. Phase 2 consists of developing a high-fidelity receiver, transmitter and environment simulator. Its goal is to find out how the METOP Specification performs in a simulated noise environment in a cost-effective receiver. The approach would be to produce a receiver using as much software as possible to perform front-end processing to take advantage of the latest high-speed PCs. Thus the COTS MODEM used in Phase 1 is performing RF demodulation along with data acquisition providing data to the receiving software. Also, environment simulator is produced using the noise patterns generated by Institute for Telecommunications Sciences (ITS) from their noise environment study.

Fong, Wai↗

NASA NTRS2002

The CCDS Data Compression Recommendations: Development and Status

The Consultative Committee for Space Data Systems (CCSDS) has been engaging in recommending data compression standards for space applications. The first effort focused on a lossless scheme that was adopted in 1997. Since then, space missions benefiting from this recommendation range from deep space probes to near Earth observatories. The cost savings result not only from reduced onboard storage and reduced bandwidth, but also in ground archive of mission data. In many instances, this recommendation also enables more science data to be collected for added scientific value. Since 1998, the compression sub-panel of CCSDS has been investigating lossy image compression schemes and is currently working towards a common solution for a single recommendation. The recommendation will fulfill the requirements for remote sensing conducted on space platforms.

Yeh, Pen-Shu↗

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 NTRSDate not supplied

Commanding Constellations (Pipeline Architecture)

Providing ground command software for constellations of spacecraft is a challenging problem. Reliable command delivery requires a feedback loop; for a constellation there will likely be an independent feedback loop for each constellation member. Each command must be sent via the proper Ground Station, which may change from one contact to the next (and may be different for different members). Dynamic configuration of the ground command software is usually required (e.g. directives to configure each member's feedback loop and assign the appropriate Ground Station). For testing purposes, there must be a way to insert command data at any level in the protocol stack. The Pipeline architecture described in this paper can support all these capabilities with a sequence of software modules (the pipeline), and a single self-identifying message format (for all types of command data and configuration directives). The Pipeline architecture is quite simple, yet it can solve some complex problems. The resulting solutions are conceptually simple, and therefore, reliable. They are also modular, and therefore, easy to distribute and extend. We first used the Pipeline architecture to design a CCSDS (Consultative Committee for Space Data Systems) Ground Telecommand system (to command one spacecraft at a time with a fixed Ground Station interface). This pipeline was later extended to include gateways to any of several Ground Stations. The resulting pipeline was then extended to handle a small constellation of spacecraft. The use of the Pipeline architecture allowed us to easily handle the increasing complexity. This paper will describe the Pipeline architecture, show how it was used to solve each of the above commanding situations, and how it can easily be extended to handle larger constellations.

Tim Ray↗

NASA NTRS2005

Secure, Network-Centric Operations of a Space-Based Asset: Cisco Router in Low Earth Orbit (CLEO) and Virtual Mission Operations Center (VMOC)

This report documents the design of network infrastructure to support operations demonstrating the concept of network-centric operations and command and control of space-based assets. These demonstrations showcase major elements of the Transformal Communication Architecture (TCA), using Internet Protocol (IP) technology. These demonstrations also rely on IP technology to perform the functions outlined in the Consultative Committee for Space Data Systems (CCSDS) Space Link Extension (SLE) document. A key element of these demonstrations was the ability to securely use networks and infrastructure owned and/or controlled by various parties. This is a sanitized technical report for public release. There is a companion report available to a limited audience. The companion report contains detailed networking addresses and other sensitive material and is available directly from William Ivancic at Glenn Research Center.

Ivancic, William↗

NASA NTRS2005

An Advanced Orbiting Systems Approach to Quality of Service in Space-Based Intelligent Communication Networks

As humans and robotic technologies are deployed in future constellation systems, differing traffic services will arise, e.g., realtime and non-realtime. In order to provide a quality of service framework that would allow humans and robotic technologies to interoperate over a wide and dynamic range of interactions, a method of classifying data as realtime or non-realtime is needed. In our paper, we present an approach that leverages the Consultative Committee for Space Data Systems (CCSDS) Advanced Orbiting Systems (AOS) data link protocol. Specifically, we redefine the AOS Transfer Frame Replay Flag in order to provide an automated store-and-forward approach on a per-service basis for use in the next-generation Interplanetary Network. In addition to addressing the problem of intermittent connectivity and associated services, we propose a follow-on methodology for prioritizing data through further modification of the AOS Transfer Frame.

Riha, Andrew P.↗

NASA NTRS2006

Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and Their Technologies to Further Enable Interoperability

To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative a requirement to standardize and control the naming conventions of very disparate systems and technologies are emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation Initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation Initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and birds of a feather activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another

Bradford, Robert N.↗

NASA NTRS2006

Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and their Technologies to Further Enable Interoperability

To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative, a requirement to standardize and control the naming conventions of very disparate systems and technologies is emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and Birds of a Feather (BoF) activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another standards body or technologies that are currently not standardized. For activities one through three, we will provide the analysis by either discipline or technology with rationale, identification and brief description of requirements and precedence. For activity four, we will provide a list of current standards bodies e.g. IETF and a list of potential candidates.

Bradford, Robert N.↗

NASA NTRS2002

The spacecraft onboard interface standardization activity

The Consultative Committee for Space Data Systems (CCSDS) is an international organization of national space agencies (such as NASA in the United States) that is organized to promote the interchange of space related information. Now, CCSDS is branching out to provide new standards for the interchange of information, and the interconnection of subsystems and devices onboard of a spacecraft. This effort is know as Spacecraft Onboard Interface (SOIF). SOIF will publish standards that will allow for the enhanced reuse of spacecraft equipment and software. SOIF expects that these standards will be well known and used within the space community, and that they will be based on or similar to the well-known Internet protocols. This paper will provide a description of the SOIF work by reviewing this work with three orthogonal views. The first of these views is the Protocol view, which describes the protocols and services that are to be implemented in order to provide the users with the advantages of the SOIF architecture. The second of these views is the Services View, which describes the data communications services that are provided to the users. And finally, the Interoperability view provides a description to users how SOIF can be used to interchange between different spacecraft data busses. This paper will give the reader an excellent introduction to the work of the international SOIF team.

spacecraft interfaces standard interfaces CCSDS↗

NASA NTRS2002

The spacecraft onboard interface standardization activity

spacecraft interfaces standard interfaces CCSDS↗

NASA NTRS2003

Standardization activity for the spacecraft onboard interfaces

The Consultative Committee for Space Data Systems (CCSDS) is an international organization of national space agencies that is organized to promote theinterchange of space related information. CCSDS is branching out to provide new standards to enhanced reuse of spacecraft equipment and software onboard of a spacecraft. This effort is know as Spacecraft Onboard Interface (SOIF). SOIF expects that these standards will be well used within the space community, and that they will be based on the well-known Internet protocols. This paper will provide a description of the SOIF work by reviewing this work with three orthogonal views. The Services View describes the data communications services that are provided to the users. The Interoperability view provides a description to users on how to use SOIF to interchange between different spacecraft data busses. And finally, the Protocol view, describes the protocols and services that are to be implemented in order to provide the users with the advantages of the SOIF architecture. This paper will give the reader an excellent introduction to the work of the international SOIF team.

Spacecraft interfaces standard interfaces CCSDS↗

NASA NTRS2000

Deep Space Network turbo decoder implementation

turbo decoder turbo code↗

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 NTRS2001

Deep Space Network turbo decoder implementation

A new decoder is being developed by the Jet Propulsion Laboratory for NASA's Deep Space Network. This unit will decode the new turbo codes, which have recently been approved by the Consultative Committee for Space Data Systems (CCSDS). Turbo codes provide up to 0.8 dB improvement in Eb/No over the current best codes used by deep space missions.

turbo codes↗