Search NASA⌕ Search

SEARCH · Search NASA

Results for “Consultative Committee for Space Data Systems”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS1985

The role of space data systems interface standards

This paper will discuss data systems interface standards including the goals and benefits in their application to space flight programs. Recent trends toward increased international cooperation in space research and applications missions have resulted in a greater emphasis on compatible interface standards among the participating agencies. The discussion will highlight the Consultative Committee for Space Data Systems (CCSDS), a consortium of 19 space agencies formed in 1982 in order to provide a technical forum for developing guidelines for compatible data systems standards among cooperating space agencies worldwide. CCSDS effort is seen as contributing significantly to the objectives of the IAF's Symposium on Space Exploration.

Stephens, R.↗
NASA NTRS2016

A Multi-Center Space Data System Prototype Based on CCSDS Standards

Deep space missions beyond earth orbit will require new methods of data communications in order to compensate for increasing RF propagation delay. The Consultative Committee for Space Data Systems (CCSDS) standard protocols Spacecraft Monitor & Control (SM&C), Asynchronous Message Service (AMS), and Delay/Disruption Tolerant Networking (DTN) provide such a method. The maturity level of this protocol set is, however, insufficient for mission inclusion at this time. This prototype is intended to provide experience which will raise the Technical Readiness Level (TRL) of these protocols..

Rich, Thomas M.↗
NASA NTRS2011

Ground System Harmonization Efforts at NASA's Goddard Space Flight Center

This slide presentation reviews the efforts made at Goddard Space Flight Center in harmonizing the ground systems to assist in collaboration in space ventures. The key elements of this effort are: (1) Moving to a Common Framework (2) Use of Consultative Committee for Space Data Systems (CCSDS) Standards (3) Collaboration Across NASA Centers (4) Collaboration Across Industry and other Space Organizations. These efforts are working to bring into harmony the GSFC systems with CCSDS standards to allow for common software, use of Commercial Off the Shelf Software and low risk development and operations and also to work toward harmonization with other NASA centers

Smith, Dan↗
NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
NASA NTRS2016

A Multi-Center Space Data System Prototype Based on CCSDS Standards

Deep space missions beyond earth orbit will require new methods of data communications in order to compensate for increasing Radio Frequency (RF) propagation delay. The Consultative Committee for Space Data Systems (CCSDS) standard protocols Spacecraft Monitor & Control (SM&C), Asynchronous Message Service (AMS), and Delay/Disruption Tolerant Networking (DTN) provide such a method. However, the maturity level of this protocol stack is insufficient for mission inclusion at this time. This Space Data System prototype is intended to provide experience which will raise the Technical Readiness Level (TRL) of this protocol set. In order to reduce costs, future missions can take advantage of these standard protocols, which will result in increased interoperability between control centers. This prototype demonstrates these capabilities by implementing a realistic space data system in which telemetry is published to control center applications at the Jet Propulsion Lab (JPL), the Marshall Space Flight Center (MSFC), and the Johnson Space Center (JSC). Reverse publishing paths for commanding from each control center are also implemented. The target vehicle consists of realistic flight computer hardware running Core Flight Software (CFS) in the integrated Power, Avionics, and Power (iPAS) Pathfinder Lab at JSC. This prototype demonstrates a potential upgrade path for future Deep Space Network (DSN) modification, in which the automatic error recovery and communication gap compensation capabilities of DTN would be exploited. In addition, SM&C provides architectural flexibility by allowing new service providers and consumers to be added efficiently anywhere in the network using the common interface provided by SM&C's Message Abstraction Layer (MAL). In FY 2015, this space data system was enhanced by adding telerobotic operations capability provided by the Robot API Delegate (RAPID) family of protocols developed at NASA. RAPID is one of several candidates for consideration and inclusion in a new international standard being developed by the CCSDS Telerobotic Operations Working Group. Software gateways for the purpose of interfacing RAPID messages with the existing SM&C based infrastructure were developed. Telerobotic monitor, control, and bridge applications were written in the RAPID framework, which were then tailored to the NAO telerobotic test article hardware, a product of Aldebaran Robotics.

Rich, Thomas M.↗
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 NTRS2018

Enabling Technologies for Deep Space Motion Imagery

From the beginning of the Space Age, imagery, particularly motion imagery, has been a part of crewed and uncrewed missions. As technologies have evolved the imagery gets better, more compelling, and more useful for operations and monitoring of systems, crew, and spacecraft. Film, video and live television have engaged the public and sparked the imaginations of engineers, scientists, and artists alike. As we look forward now to crewed missions beyond low-Earth orbit, such as the Deep Space Gateway being considered as a pre-cursor to future crewed Mars missions, there are both opportunities and challenges in implementing a multi-faceted imaging system that advances mission capabilities and technology.This paper will present a vision for an imaging system that is relevant for operations of the ISS and future crewed missions in deep space, with a detailed look at some of the key innovative technologies required to enable such a system. In addition, impacts to Space Operations, video distribution to the public and to science investigators, and video system interoperability will be presented. Opportunities where standardization can enable interoperability are also identified for those imagery and communications functions planned for inclusion in the Consultative Committee for Space Data Systems (CCSDS) Blue Book.

Grubbs, Rodney↗
NASA NTRS2015

Telescience Resource Kit (TReK)

Telescience Resource Kit (TReK) is one of the Huntsville Operations Support Center (HOSC) remote operations solutions. It can be used to monitor and control International Space Station (ISS) payloads from anywhere in the world. It is comprised of a suite of software applications and libraries that provide generic data system capabilities and access to HOSC services. The TReK Software has been operational since 2000. A new cross-platform version of TReK is under development. The new software is being released in phases during the 2014-2016 timeframe. The TReK Release 3.x series of software is the original TReK software that has been operational since 2000. This software runs on Windows. It contains capabilities to support traditional telemetry and commanding using CCSDS (Consultative Committee for Space Data Systems) packets. The TReK Release 4.x series of software is the new cross platform software. It runs on Windows and Linux. The new TReK software will support communication using standard IP protocols and traditional telemetry and commanding. All the software listed above is compatible and can be installed and run together on Windows. The new TReK software contains a suite of software that can be used by payload developers on the ground and onboard (TReK Toolkit). TReK Toolkit is a suite of lightweight libraries and utility applications for use onboard and on the ground. TReK Desktop is the full suite of TReK software -most useful on the ground. When TReK Desktop is released, the TReK installation program will provide the option to choose just the TReK Toolkit portion of the software or the full TReK Desktop suite. The ISS program is providing the TReK Toolkit software as a generic flight software capability offered as a standard service to payloads. TReK Software Verification was conducted during the April/May 2015 timeframe. Payload teams using the TReK software onboard can reference the TReK software verification. TReK will be demonstrated on-orbit running on an ISS provided T61p laptop. Target Timeframe: September 2015 -2016. The on-orbit demonstration will collect benchmark metrics, and will be used in the future to provide live demonstrations during ISS Payload Conferences. Benchmark metrics and demonstrations will address the protocols described in SSP 52050-0047 Ku Forward section 3.3.7. (Associated term: CCSDS File Delivery Protocol (CFDP)).

Lippincott, Jeff↗
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 NTRS1992

Computing Modulation Losses In A Communication System

Improved method accelerates computation of means and variances of modulation losses in radio communication system where telecommand, telemetry, and turnaround ranging signals transmitted between two stations via phase modulation with residual carrier signal. Method based on uplink and downlink signals conforming to standard promulgated by Consultative Committee for Space Data Systems. Completes computations three times as fast as "brute-force" method. Modified for application to any system involving one-way and/or two-way transmission, including retransmission.

Nguyen, Tien M.↗
NASA NTRSDate not supplied

Space-to-Ground Optical Interface Verification for the Orion Artemis II Optical (O2O) Communications Demonstration

The Orion Artemis II Optical Communications (O2O) system will demonstrate the operational utility of laser communications for the first crewed Artemis mission scheduled to launch next year. O2O will provide an optical link with data rates up to 260 Mbps return from the moon and up to 20 Mbps forward to the moon. The optical link employs a Serially Concatenated Pulse Position Modulation (SCPPM) communications signal, compliant with the Consultative Committee for Space Data Systems (CCSDS) standard, and a modulated uplink beacon for acquisition and collaborative tracking. O2O employs optical ground stations located at the White Sands Complex (WSC) and Table Mountain Facility (TMF) to support the Earth end of the link. We describe interface testing performed between the space and ground terminals to verify the physical layer communication and beacon signals.

optical↗
NASA NTRS2019

Characterization of a Photon Counting Test Bed for Space to Ground Optical Pulse Position Modulation Communications Links

The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a laboratory transmitter and receiver prototype of a space to ground optical communications link. The system is meant to emulate future deep space optical communication links, such as the first crewed flight of Orion, in which the transmitted laser is modulated using pulse position modulation and the receiver is capable of detecting single photons. The transmitter prototype consists of a software defined radio, a high extinction ratio electro-optic modulator system, and 1550 nm laser. The receiver is a scalable concept and utilizes a single-pixel array of fiber coupled superconducting nanowire single photon detectors. The transmit and receive waveforms follow the Consultative Committee for Space Data Systems (CCSDS) Optical Communications High Photon Efficiency Standard. This paper describes the transmitter and receiver prototypes as well as the system test configuration. System level tests results are presented and compared to predictions from software simulations.

Nappier, Jennifer M.↗
NASA NTRS1996

Use of CCSDS and OSI Protocols on the Advanced Communications Technology Satellite

Although ACTS (Advanced Communications Technology Satellite) provides an almost error-free channel during much of the day and under most conditions, there are times when it is not suitable for reliably error-free data communications when operating in the uncoded mode. Because coded operation is not always available to every earth station, measures must be taken in the end system to maintain adequate throughput when transferring data under adverse conditions. The most effective approach that we tested to improve performance was the addition of an 'outer' Reed-Solomon code through use of CCSDS (Consultative Committee for Space Data Systems) GOS 2 (a forward error correcting code). This addition can benefit all users of an ACTS channel including those applications that do not require totally reliable transport, but it is somewhat expensive because additional hardware is needed. Although we could not characterize the link noise statistically (it appeared to resemble uncorrelated white noise, the type that block codes are least effective in correcting), we did find that CCSDS GOS 2 gave an essentially error-free link at BER's (bit error rate) as high as 6x10(exp -4). For users that demand reliable transport, an ARQ (Automatic Repeat Queuing) protocol such as TCP (Transmission Control Protocol) or TP4 (Transport Protocol, Class 4) will probably be used. In this category, it comes as no surprise that the best choice of the protocol suites tested over ACTS was TP4 using CCSDS GOS 2. TP4 behaves very well over an error-free link which GOS 2 provides up to a point. Without forward error correction, however, TP4 service begins to degrade in the 10(exp -7)-10(exp -6) range and by 4x10(exp -6), it barely gives any throughput at all. If Congestion Avoidance is used in TP4, the degradation is even more pronounced. Fortunately, as demonstrated here, this effect can be more than compensated for by choosing the Selective Acknowledgment option. In fact, this option can enable TP4 to deliver some throughput at error rates as high as 10(exp -5).

Chirieleison, Don↗
NASA NTRS2019

Characterization of a Photon Counting Test Bed for Space to Ground Optical Pulse Position Modulation Communications Links

The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a laboratory transmitter and receiver prototype of a space-to-ground optical communications link. The system is meant to emulate future deep space optical communication links, such as the first crewed flight of Orion, in which the transmitted laser is modulated using pulse position modulation and the receiver is capable of detecting single photons. The transmitter prototype consists of a software defined radio, a high extinction ratio electro-optic modulator system, and a 1550 nm laser. The receiver is a scalable concept and utilizes a single-pixel array of fiber coupled superconducting nanowire single photon detectors. The transmit and receive waveforms follow the Consultative Committee for Space Data Systems (CCSDS) Optical Communications Coding and Synchronization Standard. A software model of the optical transmitter and receiver has also been implemented to predict performance of the optical test bed. This paper describes the transmitter and receiver prototypes as well as the system test configuration. System level tests results are presented and shown to align with predictions from software simulations. The validated software model can be used to in the future to reduce the design cycle of optical communications systems.

software defined radio↗
NASA NTRS2016

Next Generation Flight Displays Using HTML5

The Human Integrated Vehicles and Environments (HIVE) lab at Johnson Space Center (JSC) is focused on bringing together inter-disciplinary talent to design and integrate innovative human interface technologies for next generation manned spacecraft. As part of this objective, my summer internship project centered on an ongoing investigation in to building flight displays using the HTML5 standard. Specifically, the goals of my project were to build and demo "flight-like" crew and wearable displays as well as create a webserver for live systems being developed by the Advanced Exploration Systems (AES) program. In parallel to my project, a LabVIEW application, called a display server, was created by the HIVE that uses an XTCE (XML (Extensible Markup Language) Telemetry and Command Exchange) parser and CCSDS (Consultative Committee for Space Data System) space packet decoder to translate telemetry items sent by the CFS (Core Flight Software) over User Datagram Protocol (UDP). It was the webserver's job to receive these UDP messages and send them to the displays. To accomplish this functionality, I utilized Node.js and the accompanying Express framework. On the display side, I was responsible for creating the power system (AMPS) displays. I did this by using HTML5, CSS and JavaScript to create web pages that could update and change dynamically based on the data they received from the webserver. At this point, I have not started on the commanding, being able to send back to the CFS, portion of the displays but hope to have this functionality working by the completion of my internship. I also created a way to test the webserver's functionality without the display server by making a JavaScript application that read in a comma-separate values (CSV) file and converted it to XML which was then sent over UDP. One of the major requirements of my project was to build everything using as little preexisting code as possible, which I accomplished by only using a handful of JavaScript libraries. As a side project, I created a model of the HIVE lab and Building 29 using SketchUp. I obtained the floorplans of the building from the JSC Geographic Information Systems (GIS), which were computer-aided design (CAD) files, and imported them into SketchUp. I then took those floorplans and created a 3D model of the building from them. Working in conjunction with the Hybrid Reality lab in Building 32, the SketchUp model was imported into Unreal Engine for use with the HTC Vive. Using the Vive, I was able to interact with the model I created in virtual reality (VR). The purpose of this side project was to be able to visualize potential lab layouts and mockup designs as they are in development in order to finalize design decisions. Pending approval, the model that I created will be used in the Build-As-You-Test: Can Hybrid Reality Improve the SE/HSI Design Process project in the fall. Getting the opportunity to work at NASA has been one of the most memorable experiences of my life. Over the course of my internship, I improved my programming and web development abilities substantially. I will take all the skills and experiences I have had while at NASA back to school with me in the fall and hope to pursue a career in the aerospace industry after graduating in the spring.

Greenwood, Brian↗
NASA NTRS1994

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↗
NASA NTRS1988

The behavior of a Costas loop in the presence of space telemetry signals

The telemetry modulation index, telemetry bit rate, subcarrier waveform, and subcarrier frequency are shown to be the key system parameters that contribute to the performance degradation of a Costas loop in the presence of space telemetry signals. The effects of the Doppler in the loop are also investigated. The results of this study were input to the Consultative Committee for Space Data Systems (CCSDS) for consideration in the future standard suppressed-carrier space telemetry system.

Nguyen, T. M.↗
NASA NTRS2009

Developing a Standard Method for Link-Layer Security of CCSDS Space Communications

Communications security for space systems has been a specialized field generally far removed from considerations of mission interoperability and cross-support in fact, these considerations often have been viewed as intrinsically opposed to security objectives. The space communications protocols defined by the Consultative Committee for Space Data Systems (CCSDS) have a twenty-five year history of successful use in over 400 missions. While the CCSDS Telemetry, Telecommand, and Advancing Orbiting Systems protocols for use at OSI Layer 2 are operationally mature, there has been no direct support within these protocols for communications security techniques. Link-layer communications security has been successfully implemented in the past using mission-unique methods, but never before with an objective of facilitating cross-support and interoperability. This paper discusses the design of a standard method for cryptographic authentication, encryption, and replay protection at the data link layer that can be integrated into existing CCSDS protocols without disruption to legacy communications services. Integrating cryptographic operations into existing data structures and processing sequences requires a careful assessment of the potential impediments within spacecraft, ground stations, and operations centers. The objective of this work is to provide a sound method for cryptographic encapsulation of frame data that also facilitates Layer 2 virtual channel switching, such that a mission may procure data transport services as needed without involving third parties in the cryptographic processing, or split independent data streams for separate cryptographic processing.

Biggerstaff, Craig↗