Search NASA⌕ Search

SEARCH · Search NASA

Results for “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.

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

At least 235 records · Page 13

Space Qualified High Speed Reed Solomon Encoder

This paper reports a Class S CCSDS recommendation Reed Solomon encoder circuit baselined for several NASA programs. The chip is fabricated using United Technologies Microelectronics Center's UTE-R radiation-hardened gate array family, contains 64,000 p-n transistor pairs, and operates at a sustained output data rate of 200 MBits/s. The chip features a pin selectable message interleave depth of from 1 to 8 and supports output block lengths of 33 to 255 bytes. The UTE-R process is reported to produce parts that are radiation hardened to 16 Rads (Si) total dose and 1.0(exp -10) errors/bit-day.

Gambles, Jody W.↗

SAMPEX payload operation control center implementation

The Solar Anomolous and Magnetospheric Explorer (SAMPEX) satellite was launched in July 1992. It was the first in the NASA Small Explorer (SMEX) series. In building the real-time control center facility, several new mission support challenges had to be met: CCSDS telemetry and command format, 900 Kbps telemetry data, and shorter turn-around time for control center development than previous missions. The SAMPEX Payload Operations Control Ccnter (POCC) was also the first control center for a new satellite to be based on the Transportable Payload Operations Control Center (TPOCC) system architecture and methodology. This approach has both guided the implementation of the SAMPEX control center and provided some of the building blocks. By using the TPOCC architecture to build the SAMPEX POCC, the real-time operations area was miniaturized into one room, whereas previous missions needed multiple large rooms. The development cost of the SAMPEX POCC was reduced from previous missions and will provide for further cost savings in the future SMEX satellites. This paper describes the system as built and some of the enhancements in progress to create this teleoperations environment.

Mandl, Daniel↗

A reference model for space data system interconnection services

The widespread adoption of standard packet-based data communication protocols and services for spaceflight missions provides the foundation for other standard space data handling services. These space data handling services can be defined as increasingly sophisticated processing of data or information received from lower-level services, using a layering approach made famous in the International Organization for Standardization (ISO) Open System Interconnection Reference Model (OSI-RM). The Space Data System Interconnection Reference Model (SDSI-RM) incorporates the conventions of the OSIRM to provide a framework within which a complete set of space data handling services can be defined. The use of the SDSI-RM is illustrated through its application to data handling services and protocols that have been defined by, or are under consideration by, the Consultative Committee for Space Data Systems (CCSDS).

Pietras, John↗

The European Space Agency standard for space packet utilisation

This paper presents the ESA concept for the use of CCSDS defined Telemetry and Telecommand Packets at the application level. These Packets are used to monitor and control remotely a space born application. This concept is defined in a Packet Utilisation Standard (PUS) which should become applicable for all ESA missions using Packets. The production of this standard is under the responsibility of an ESA standardization group called 'COES'.

Kaufeler, J.-F.↗

Decoder synchronization for deep space missions

The Consultative Committee for Space Data Standards (CCSDS) recommends that space communication links employ a concatenated, error-correcting, channel-coding system in which the inner code is a convolutional (7,1/2) code and the outer code is a (255,223) Reed-Solomon code. The traditional implementation is to perform the node synchronization for the Viterbi decoder and the frame synchronization for the Reed-Solomon decoder as separate, sequential operations. This article discusses a unified synchronization technique that is required for deep space missions that have data rates and signal-to-noise ratios (SNR's) that are extremely low. This technique combines frame synchronization in the bit and symbol domains and traditional accumulated-metric growth techniques to establish a joint frame and node synchronization. A variation on this technique is used for the Galileo spacecraft on its Jupiter-bound mission.

Statman, J. I.↗

Role of formats in the life cycle of data

This paper's perspective is based on the author's experience generating, analyzing, archiving, and distributing data obtained from satellites, and on the experience gained in data modeling and the development of standards for data understanding under the Consultative Committee for Space Data Systems (CCSDS). Data formats are used to represent all information in digital form, and thus play a major role in all interchanges and access to this information. The need to more efficiently manage and process rapidly growing quantities of data, and to preserve the information contained therein, continue to drive a great interest in data formats. The purpose of this paper is to examine the role of formats as they support the use of data within a space agency. The life-cycle identified is only one of many variations that would be recognized by those familiar with the 'space business', however it is expected that most of the issues raised will be pertinent to other 'space business' life cycles and to other 'non-space' disciplines as well.

Sawyer, Don↗

A reference model for scientific information interchange

This paper presents an overview of an Information Interchange Reference Model (IIRM) currently being developed by individuals participating in the Consultative Committee for Space Data Systems (CCSDS) Panel 2, the Planetary Data Systems (PDS), and the Committee on Earth Observing Satellites (CEOS). This is an ongoing research activity and is not an official position by these bodies. This reference model provides a framework for describing and assessing current and proposed methodologies for information interchange within and among the space agencies. It is hoped that this model will improve interoperability between the various methodologies. As such, this model attempts to address key information interchange issues as seen by the producers and users of space-related data and to put them into a coherent framework. Information is understood as the knowledge (e.g., the scientific content) represented by data. Therefore, concern is not primarily on mechanisms for transferring data from user to user (e.g., compact disk read-only memory (CD-ROM), wide-area networks, optical tape, and so forth) but on how information is encoded as data and how the information content is maintained with minimal loss or distortion during transmittal. The model assumes open systems, which means that the protocols or methods used should be fully described and the descriptions publicly available. Ideally these protocols are promoted by recognized standards organizations using processes that permit involvement by those most likely to be affected, thereby enhancing the protocol's stability and the likelihood of wide support.

Reich, Lou↗

A high-speed lossless data compression system for space applications

This paper reports on the integration of a lossless data compression/decompression chipset into a space data system architecture. For its compression engine, the data system incorporates the Universal Source Encoder (USE) designed for the NASA/Goddard Space Flight Center. Currently, the data compression testbed generates video frames consisting of 512 lines of 512 pixels having 8-bit resolution. Each image is passed through the USE where the lines are internally partitioned into 16-word blocks. These blocks are adaptively encoded across widely varying entropy levels using a Rice 12-option set coding algorithm. The current system operates at an Input/Output rate of 10 Msamples/s or 80 Mbits/s for each buffered input line. Frame and line synchronization for each image are maintained through the use of uniquely decodable command words. Length information of each variable length compressed image line is also included in the output stream. The data and command information are passed to the next stage of the system architecture through a serial fiber-optic transmitter. The initial segment of this stage consists of packetizer hardware which adds an appropriate CCSDS header to the received source data. An uncompressed mode is optionally available to pass image lines directly to the packetizer hardware. A data decompression testbed has also been developed to confirm the data compression operation.

Miko, Joe↗

The proposed HDTV schemes and the NASA network

Results of the simulation of high definition television (HDTV) techniques in the context of their application to transmit HDTV sequences over the NASA network are presented. Various tradeoffs involved in selecting the different services available on the NASA network are discussed. The possibility of transmitting an HDTV-like signal over the CCSDS network is investigated. Some suitable approaches are suggested.

Chen, Y. C.↗

Evolutionary Telemetry and Command Processor (TCP) architecture

A low cost, modular, high performance, and compact Telemetry and Command Processor (TCP) is being built as the foundation of command and data handling subsystems for the next generation of satellites. The TCP product line will support command and telemetry requirements for small to large spacecraft and from low to high rate data transmission. It is compatible with the latest TDRSS, STDN and SGLS transponders and provides CCSDS protocol communications in addition to standard TDM formats. Its high performance computer provides computing resources for hosted flight software. Layered and modular software provides common services using standardized interfaces to applications thereby enhancing software re-use, transportability, and interoperability. The TCP architecture is based on existing standards, distributed networking, distributed and open system computing, and packet technology. The first TCP application is planned for the 94 SDIO SPAS 3 mission. The architecture enhances rapid tailoring of functions thereby reducing costs and schedules developed for individual spacecraft missions.

Schneider, John R.↗

Applications of massively parallel computers in telemetry processing

Telemetry processing refers to the reconstruction of full resolution raw instrumentation data with artifacts, of space and ground recording and transmission, removed. Being the first processing phase of satellite data, this process is also referred to as level-zero processing. This study is aimed at investigating the use of massively parallel computing technology in providing level-zero processing to spaceflights that adhere to the recommendations of the Consultative Committee on Space Data Systems (CCSDS). The workload characteristics, of level-zero processing, are used to identify processing requirements in high-performance computing systems. An example of level-zero functions on a SIMD MPP, such as the MasPar, is discussed. The requirements in this paper are based in part on the Earth Observing System (EOS) Data and Operation System (EDOS).

El-Ghazawi, Tarek A.↗

The Pacor 2 expert system: A case-based reasoning approach to troubleshooting

The Packet Processor 2 (Pacor 2) Data Capture Facility (DCF) acquires, captures, and performs level-zero processing of packet telemetry for spaceflight missions that adhere to communication services recommendations established by the Consultative Committee for Space Data Systems (CCSDS). A major goal of this project is to reduce life-cycle costs. One way to achieve this goal is to increase automation. Through automation, using expert systems, and other technologies, staffing requirements will remain static, which will enable the same number of analysts to support more missions. Analysts provide packet telemetry data evaluation and analysis services for all data received. Data that passes this evaluation is forwarded to the Data Distribution Facility (DDF) and released to scientists. Through troubleshooting, data that fails this evaluation is dumped and analyzed to determine if its quality can be improved before it is released. This paper describes a proof-of-concept prototype that troubleshoots data quality problems. The Pacor 2 expert system prototype uses the case-based reasoning (CBR) approach to development, an alternative to a rule-based approach. Because Pacor 2 is not operational, the prototype has been developed using cases that describe existing troubleshooting experience from currently operating missions. Through CBR, this experience will be available to analysts when Pacor 2 becomes operational. As Pacor 2 unique experience is gained, analysts will update the case base. In essence, analysts are training the system as they learn. Once the system has learned the cases most likely to recur, it can serve as an aide to inexperienced analysts, a refresher to experienced analysts for infrequently occurring problems, or a training tool for new analysts. The Expert System Development Methodology (ESDM) is being used to guide development.

Sary, Charisse↗

OOD/OOP experience in the Science Operations Center part of the ground system for X ray Timing Explorer mission

The Science Operations Center (SOC) for the X-ray Timing Explorer (XTE) mission is an important component of the XTE ground system. Its mandate includes: (1) command and telemetry for the three XTE instruments, using CCSDS standards; (2) monitoring of the real-time science operations, reconfiguration of the experiment and the instruments, and real-time commanding to address the targets of opportunity (TOO) and alternate observations; and (3) analysis, processing, and archival of the XTE telemetry, and the timely delivery of the data products to the principal investigator (PI) teams and the guest observers (GO). The SOC has two major components: the science operations facility (SOF) that addresses the first two objectives stated above and the guest observer facility (GOF) that addresses the third. The SOF has subscribed to the object oriented design and implementation; while the GOF uses the traditional approach in order to take advantage of the existing software developed in support of previous missions. This paper details the SOF development using the object oriented design (OOD), and its implementation using the object oriented programming (OOP) in C++ under Unix environment on client-server architecture using Sun workstations. It also illustrates how the object oriented (OO) and the traditional approaches coexist in SOF and GOF, the lessons learned, and how the OOD facilitated the distributed software development collaboratively by four different teams. Details are presented for the SOF system, its major subsystems, its interfaces with the rest of the XTE ground data system, and its design and implementation approaches.

Choudhary, Abdur Rahim↗

The Advanced Orbiting Systems Testbed Program: Results to date

The Consultative Committee for Space Data Systems (CCSDS) Recommendations for Packet Telemetry (PT) and Advanced Orbiting Systems (AOS) propose standard solutions to data handling problems common to many types of space missions. The Recommendations address only space/ground and space/space data handling systems. Goddard Space Flight Center's (GSFC's) AOS Testbed (AOST) Program was initiated to better understand the Recommendations and their impact on real-world systems, and to examine the extended domain of ground/ground data handling systems. The results and products of the Program will reduce the uncertainties associated with the development of operational space and ground systems that implement the Recommendations.

Otranto, John F.↗

Spacecraft Data Simulator for the test of level zero processing systems

The Microelectronic Systems Branch (MSB) at Goddard Space Flight Center (GSFC) has developed a Spacecraft Data Simulator (SDS) to support the development, test, and verification of prototype and production Level Zero Processing (LZP) systems. Based on a disk array system, the SDS is capable of generating large test data sets up to 5 Gigabytes and outputting serial test data at rates up to 80 Mbps. The SDS supports data formats including NASA Communication (Nascom) blocks, Consultative Committee for Space Data System (CCSDS) Version 1 & 2 frames and packets, and all the Advanced Orbiting Systems (AOS) services. The capability to simulate both sequential and non-sequential time-ordered downlink data streams with errors and gaps is crucial to test LZP systems. This paper describes the system architecture, hardware and software designs, and test data designs. Examples of test data designs are included to illustrate the application of the SDS.

Shi, Jeff↗

A system study for satellite operation and control in next generation

Ever since the first satellite, ETS-1, in 1975, 28 NASDA satellites in total have been launched. With regards to satellite operations, NASDA has developed realtime TLM/CMD processing systems which could be commonly used for different types of satellite. Presently the third generation system is operational. Meanwhile, the recent trend of satellite operations is becoming more complicated, for example, CCSDS-adapted Satellites are emerging and computer technology is developing quite rapidly. Moreover, NASDA's role in satellite operations is changing from mainly Satellite Bus operations to experimental/whole satellite missions operations. Considering these circumstances, NASDA has initiated a study for the next generation system which is suitable for operations of future satellites keeping in mind the following viewpoints: (1) demands from mission support; (2) trend of satellite design; and (3) progress of computer environment. This is an interim report of the study.

Nakayama, K.↗

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↗

EDOS operations concept and development approach

The Earth Observing System (EOS) Data and Operations System (EDOS) is being developed by the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC) for the capture, level zero processing, distribution, and backup archiving of high speed telemetry data received from EOS spacecraft. All data received will conform to the Consultative Committee for Space Data Standards (CCSDS) recommendations. The major EDOS goals are to: (1) minimize EOS program costs to implement and operate EDOS; (2) respond effectively to EOS growth requirements; and (3) maintain compatibility with existing and enhanced versions of NASA institutional systems required to support EOS spacecraft. In order to meet these goals, the following objectives have been defined for EDOS: (1) standardize EDOS interfaces to maximize utility for future requirements; (2) emphasize life-cycle cost (LCC) considerations (rather than procurement costs) in making design decisions and meeting reliability, maintainability, availability (RMA) and upgradability requirements; (3) implement data-driven operations to the maximum extent possible to minimize staffing requirements and to maximize system responsiveness; (4) provide a system capable of simultaneously supporting multiple spacecraft, each in different phases of their life-cycles; (5) provide for technology insertion features to accommodate growth and future LCC reductions during the operations phase; and (6) provide a system that is sufficiently robust to accommodate incremental performance upgrades while supporting operations. Operations concept working group meetings were facilitated to help develop the EDOS operations concept. This provided a cohesive concept that met with approval of responsible personnel from the start. This approach not only speeded up the development process by reducing review cycles, it also provided a medium for generating good ideas that were immediately molded into feasible concepts. The operations concept was then used as a basis for the EDOS specification. When it was felt that concept elements did not support detailed requirements, the facilitator process was used to resolve discrepancies or to add new concept elements to support the specification. This method provided an ongoing revisal of the operations concept and prevented large revisions at the end of the requirement analysis phase of system development.

Knoble, G.↗