Message transfer service for space applications
Explore the source record for details and available documents.
CCSDS standards communications space data systems↗
SEARCH · Engineering Papers
Results for “space data systems standards”
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.
Real Time Optical Receiver Project
The goals for the Real Time Optical Receiver project are to Infuse Consultative Committee for Space Data Systems High Photon Efficiency standard into missions, such as Artemis and to provide a real time ground receiver solution (fiber device, detector, real time FPGA-based receiver) that is: (1) Scalable: data rate, atmosphere conditions, telescope aperture, etc., and (2) Uses COTS components when available and work with companies to move custom parts to COTS.
Katz, Evan J.↗
The advanced orbiting systems testbed program: Results to date
The Consultative Committee for Space Data Systems Recommendations for Packet Telemetry 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 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. Central to the AOST Program are the development of an end-to-end Testbed and its use in a comprehensive testing program. Other Program activities include flight-qualifiable component development, supporting studies, and knowledge dissemination. 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. The results presented in this paper include architectural issues, a draft proposed standardized test suite and flight-qualifiable components.
Newsome, Penny A.↗
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.↗
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↗
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↗
Standardized Spacecraft Onboard Interfaces
The Consultative Committee for Space Data Systems (CCSDS), an international organization of national space agencies, is branching out to provide new standards to enhanced reuse of onboard spacecraft equipment and software. These Spacecraft Onboard Interface (SOIF) standards will be, in part, based on the well-known Internet protocols. This paper will provide a description of the SOIF work by describing three orthogonal views: the Services View that describes data communications services, the Interoperability view shows how to exchange data and messages between different spacecraft elements, and the Protocol view, that describes the SOIF protocols and services. We will also provide a description of the present state of the services that will be provided to SOIF users, and are the basis of the utility of these standards.
space interfaces↗
Verification of technical elements of the advanced spacecraft based upon the CCSDS recommendation
We are going to meet the era when advanced spacecraft such as space stations are developed and operated. The current system of the satellite operations control will need to undergo many changes. We consider that the future system will require the following functions: the function for interchanging data between international agencies, processing the various kinds of space data, and distributing data as many unspecified users require. However, we have to solve the following problems in order to satisfy these requirements: the problem of standardization of space data communication protocol, establishment of multimedia data management method, and standardization of the user interface. This paper describes three techniques to solve the above mentioned problems. That is, standardization of the data communication protocol between space and ground by AOS (Advanced Orbiting System) protocol of CCSDS (Consultative Committee for Space Data Systems) Recommendation, management of multimedia data by catalog reference, standardization of user interface by SFDU(Standard Formatted Data Unit) of CCSDS Recommendation.
Hara, Hideo↗
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↗
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↗
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.↗
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.↗
The NASA data systems standardization program - Rationale and scope
A simple, top level logical reference model of the NASA Space Transportation System's end-to-end data system is being developed which can identify the functions and services of the system. Each function or service may be mapped into specific physical subsystems, so that interface relationships are evident and 'standard' protocols may be identified for development. By means of this interface standardization, subsystems can be designed not only independently and in parallel, but with confidence that when the subsystems are aggregated, the end-to-end system will operate efficiently and at low cost. This standardization effort has thus far been principally directed toward space-to-ground communications links.
Smylie, R. E.↗
A Real-Time Optical Ground Receiver for Photon Starved Environments
The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a photon-counting optical ground receiver for pulse-position modulated signals. The real-time receiver system includes a fiber interconnect, superconducting nanowire single-photon detectors (SNSPDs), and a real-time field programmable gate array (FPGA) based receiver. The fiber interconnect and SNSPDs are implemented with two different configurations. In the first, a 7-channel few-mode fiber photonic lantern couples the light from the telescope to 7 single-pixel few-mode fiber coupled SNSPDs. In the second configuration, a few-mode fiber couples light to a 16-pixel monolithic SNSPD array. The real-time FPGA-based receiver performs combining of up to 16 SNSPD channels, symbol timing recovery, demodulation, and decoding. The system is scalable with data rates ranging from 20 Mbps to 267 Mbps. It is compliant with the Consultative Committee for Space Data Systems (CCSDS) Optical Communications Coding and Synchronization Standard. This standard will be used in NASA deep space and other low photon flux missions, such as in the Orion Artemis-2 Optical Communications System (O2O) demonstration, planned for the first crewed flight of Orion. This paper describes the scalable real-time optical receiver system and presents characterization test results.
optical communications↗
A Real-Time Optical Ground Receiver for Photon Starved Environments
The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) has developed a photon-counting optical ground receiver for pulse-position modulated signals. The real-time receiver system includes a fiber interconnect, superconducting nanowire single-photon detectors (SNSPDs), and a real-time field programmable gate array (FPGA) based receiver. The fiber interconnect and SNSPDs are implemented with two different configurations. In the first, a 7-channel few-mode fiber photonic lantern couples the light from the telescope to 7 single-pixel few-mode fiber coupled SNSPDs. In the second configuration, a few-mode fiber couples light to a 16-pixel monolithic SNSPD array. The real-time FPGA-based receiver performs combining of up to 16 SNSPD channels, symbol timing recovery, demodulation, and decoding. The system is scalable with data rates ranging from 20 Mbps to 267 Mbps. It is compliant with the Consultative Committee for Space Data Systems (CCSDS) Optical Communications Coding and Synchronization Standard. This standard will be used in NASA deep space and other low photon flux missions, such as in the Orion Artemis-2 Optical Communications System (O2O) demonstration, planned for the first crewed flight of Orion. This paper describes the scalable real-time optical receiver system and presents characterization test results.
optical communications↗
Asynchronous Message Service for Deep Space Mission Operations
While the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) provides internationally standardized file transfer functionality that can offer significant benefits for deep space mission operations, not all spacecraft communication requirements are necessarily best met by file transfer. In particular, continuous event-driven asynchronous message exchange may also be useful for communications with, among, and aboard spacecraft. CCSDS has therefore undertaken the development of a new Asynchronous Message Service (AMS) standard, designed to provide common functionality over a wide variety of underlying transport services, ranging from shared memory message queues to CCSDS telemetry systems. The present paper discusses the design concepts of AMS, their applicability to deep space mission operations problems, and the results of preliminary performance testing obtained from exercise of a prototype implementation.
asynchronous message exchanges↗
NASA Near Earth Network (NEN) DVB-S2 Demonstration Testing for Enhancing Higher Data Rates for CubeSat/Small Satellite Missions at X-/Ka-band
National Aeronautics and Space Administration (NASA) CubeSat/SmallSat missions are moving to higher data rates. Digital Video Broadcast, Satellite Second Generation (DVB-S2) is a communications standard that uses power and bandwidth efficient modulation and coding techniques to deliver performance approaching radio frequency (RF) channel theoretical limits. The Near Earth Network (NEN) will test DVB-S2’s ability to provide higher data rates for CubeSat/SmallSat missions at X-band and Ka-band at Wallops Flight Facility (WFF). The goal is to upgrade the NEN with DVB-S2 to increase science data return for missions and enable support for more CubeSat/SmallSat missions. This paper describes NEN DVB-S2 X-band and Ka-band demonstration objectives, scope, and performance measures as well as NEN channel test configuration. The NEN has planned 2020 tests to demonstrate all modulation and coding schemes in the Consultative Committee for Space Data Systems (CCSDS) DVB-S2 standard over X-band and Ka-band. A link analysis study for the trade-offs among achievable data rates, modulations, codes, spacecraft antenna sizes and power amplifiers (PA) is provided. This paper identifies Commercial off-the-shelf (COTS) CubeSat/SmallSat X-band and Ka-band communication systems and discusses low cost DVB-S2 X-band software defined radio (SDR) transmitter development concepts and implementation with a practical system for CubeSats/SmallSats.
Yen Wong↗
Space Link Extension Protocol Emulation for High-Throughput, High-Latency Network Connections
New space missions require higher data rates and new protocols to meet these requirements. These high data rate space communication links push the limitations of not only the space communication links, but of the ground communication networks and protocols which forward user data to remote ground stations (GS) for transmission. The Consultative Committee for Space Data Systems, (CCSDS) Space Link Extension (SLE) standard protocol is one protocol that has been proposed for use by the NASA Space Network (SN) Ground Segment Sustainment (SGSS) program. New protocol implementations must be carefully tested to ensure that they provide the required functionality, especially because of the remote nature of spacecraft. The SLE protocol standard has been tested in the NASA Glenn Research Center's SCENIC Emulation Lab in order to observe its operation under realistic network delay conditions. More specifically, the delay between then NASA Integrated Services Network (NISN) and spacecraft has been emulated. The round trip time (RTT) delay for the continental NISN network has been shown to be up to 120ms; as such the SLE protocol was tested with network delays ranging from 0ms to 200ms. Both a base network condition and an SLE connection were tested with these RTT delays, and the reaction of both network tests to the delay conditions were recorded. Throughput for both of these links was set at 1.2Gbps. The results will show that, in the presence of realistic network delay, the SLE link throughput is significantly reduced while the base network throughput however remained at the 1.2Gbps specification. The decrease in SLE throughput has been attributed to the implementation's use of blocking calls. The decrease in throughput is not acceptable for high data rate links, as the link requires constant data a flow in order for spacecraft and ground radios to stay synchronized, unless significant data is queued a the ground station. In cases where queuing the data is not an option, such as during real time transmissions, the SLE implementation cannot support high data rate communication.
Computer Networking↗