Engineering Papers⌕ Search

SEARCH · Engineering Papers

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

31 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

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.↗
NASA NTRS2019

The Seismic Experiment for Interior Structure (SEIS): Experiment Data Distribution

The six sensors of SEIS (The Seismic Experiment for Interior Structure) [- one of three primary instruments on NASA's Mars Lander Insight] cover a broad range of the seismic bandwidth, from 0.01 hertz to 50 hertz, with possible extension to longer periods. Data are transmitted in the form of three continuous VBB (Very Broad-Band) components at 2 samples per second (sps), an estimation of the short period (SP) energy content from the SP at 1 sps, and a continuous compound VBB/SP vertical axis at 10 sps. The continuous streams are augmented by requested event data with sample rates from 20 to 100 sps. SEIS data products are downlinked from the spacecraft in raw CCSDS (Consultative Committee for Space Data Systems) packets and converted to both the Standard for the Exchange of Earthquake Data (SEED) format files and ASCII tables (GeoCSV) for analysis and archiving. Metadata are available in dataless SEED and StionXML. Time series data (waveforms) are available in miniseed and GeoCSV. Data are distributed according to FDSN (Federation of Digital Seismograph Networks - http://www.fdsn.org) formats and interfaces. Wind, pressure and temperature data from the Auxiliary Payload Sensor Suite (APSS) will also be available in SEED format, and can be used for decorrelation and diagnostic purposes on SEIS.

Pardo, Constanza↗
NASA NTRS2016

Using SpaceWire Time Codes for Spacecraft Time Synchronization

This paper describes how SpaceWire Time Codes can be used for synchronizing time within various subsystems of a spacecraft as well as, maintaining a common time reference needed for coordinating operations within a spacecraft. The algorithms to account for inaccuracies in the time distribution method were based on the NASA-4009 Space Telecommunication Radio System (STRS) standard [1], which defined an interface for synchronizing clocks running at different tick rates and tick resolutions.

SpaceWire Time Distribution Protocol↗
NASA NTRS2011

Motion Imagery and Robotics Application (MIRA)

Objectives include: I. Prototype a camera service leveraging the CCSDS Integrated protocol stack (MIRA/SM&C/AMS/DTN): a) CCSDS MIRA Service (New). b) Spacecraft Monitor and Control (SM&C). c) Asynchronous Messaging Service (AMS). d) Delay/Disruption Tolerant Networking (DTN). II. Additional MIRA Objectives: a) Demo of Camera Control through ISS using CCSDS protocol stack (Berlin, May 2011). b) Verify that the CCSDS standards stack can provide end-to-end space camera services across ground and space environments. c) Test interoperability of various CCSDS protocol standards. d) Identify overlaps in the design and implementations of the CCSDS protocol standards. e) Identify software incompatibilities in the CCSDS stack interfaces. f) Provide redlines to the SM&C, AMS, and DTN working groups. d) Enable the CCSDS MIRA service for potential use in ISS Kibo camera commanding. e) Assist in long-term evolution of this entire group of CCSDS standards to TRL 6 or greater.

Martinez, Lindolfo↗
NASA NTRS2009

Prototype Interoperability Document between NASA-JSC and DLR-GSOC Describing the CCSDS SM and C Mission Operations Prototype

The purpose of the PROTOTYPE INTEROPERABILITY DOCUMENT is to document the design and interfaces for the service providers and consumers of a Mission Operations prototype between JSC-OTF and DLR-GSOC. The primary goal is to test the interoperability sections of the CCSDS Spacecraft Monitor & Control (SM&C) Mission Operations (MO) specifications between both control centers. An additional goal is to provide feedback to the Spacecraft Monitor and Control (SM&C) working group through the Review Item Disposition (RID) process. This Prototype is considered a proof of concept and should increase the knowledge base of the CCSDS SM&C Mission Operations standards. No operational capabilities will be provided. The CCSDS Mission Operations (MO) initiative was previously called Spacecraft Monitor and Control (SM&C). The specifications have been renamed to better reflect the scope and overall objectives. The working group retains the name Spacecraft Monitor and Control working group and is under the Mission Operations and Information Services Area (MOIMS) of CCSDS. This document will refer to the specifications as SM&C Mission Operations, Mission Operations or just MO.

Lucord, Steve A.↗
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 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 NTRS1994

The CCSDS return all frames Space Link Extension service

Existing Consultative Committee for Space Data Systems (CCSDS) Recommendations for Telemetry Channel Coding, Packet Telemetry, Advanced Orbiting Systems, and Telecommand have facilitated cross-support between Agencies by standardizing the link between spacecraft and ground terminal. CCSDS is currently defining a set of Space Link Extension (SLE) services that will enable remote science and mission operations facilities to access the ground termination of the Space Link services in a standard manner. The first SLE service to be defined is the Return All Frames (RAF) service. The RAF service delivers all CCSDS link-layer frames received on a single space link physical channel. The service provides both on-line and off-line data transfer modes to accommodate the variety of access methods typical of space mission operations. This paper describes the RAF service as of the Summer of 1994. It characterizes the behavior of the service as seen across the interface between the user and the service and gives an overview of the interactions involved in setting up and operating the service in a cross-support environment.

Uhrig, Hans↗
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 NTRS2000

The NASA Spacecraft Transponding Modem

A new deep space transponder is being developed by the Jet Propulsion Laboratory for NASA. The Spacecraft Transponding Modem (STM) implements the standard transponder functions and the channel service functions that have previously resided in spacecraft Command/Data Subsystems. The STM uses custom ASICs, MMICs, and MCMs to reduce the active device parts count to 70, mass to I kg, and volume to 524 cc. The first STMs will be flown on missions launching in the 2003 time frame. The STM tracks an X-band uplink signal and provides both X-band and Ka-band downlinks, either coherent or non-coherent with the uplink. A NASA standard Command Detector Unit is integrated into the STM, along with a codeblock processor and a hardware command decoder. The decoded command codeblocks are output to the spacecraft command/data subsystem. Virtual Channel 0 (VC-0) (hardware) commands are processed and output as critical controller (CRC) commands. Downlink telemetry is received from the spacecraft data subsystem as telemetry frames. The STM provides the following downlink coding options: the standard CCSDS (7-1/2) convolutional coding, ReedSolomon coding with interleave depths one and five, (15-1/6) convolutional coding, and Turbo coding with rates 1/3 and 1/6. The downlink symbol rates can be linearly ramped to match the G/T curve of the receiving station, providing up to a 1 dB increase in data return. Data rates range from 5 bits per second (bps) to 24 Mbps, with three modulation modes provided: modulated subcarrier (3 different frequencies provided), biphase-L modulated direct on carrier, and Offset QPSK. Also, the capability to generate one of four non-harmonically related telemetry beacon tones is provided, to allow for a simple spacecraft status monitoring scheme for cruise phases of missions. Three ranging modes are provided: standard turn around ranging, regenerative pseudo-noise (PN) ranging, and Differential One-way Ranging (DOR) tones. The regenerative ranging provides the capability of increasing the ground received ranging SNR by up to 30 dB. Two different avionics interfaces to the command/data subsystem's data bus are provided: a MIL STD 1553B bus or an industry standard PCI interface. Digital interfaces provide the capability to control antenna selection (e.g., switching between high gain and low gain antennas) and antenna pointing (for future steered Ka-band antennas).

Berner, Jeff B.↗
NASA NTRS2004

Downlink Data Multiplexer

A multiplexer/demultiplexer system has been developed to enable the transmission, over a single channel, of four data streams generated by a variety of sources at different (including variable) bit rates. In the original intended application, replicas of this multiplexer/demultiplexer system would be incorporated into the spacecraft-to-ground communication systems of the space shuttles. The multiplexer of each system would be installed in the spacecraft, where it would acquire and process data from such sources as commercial digital camcorders, video tape recorders, and the spacecraft telemetry system. The demultiplexer of each system would be installed in a ground station. Purely terrestrial systems of similar design could be attractive for use in situations in which there are requirements to transmit multiple streams of high-quality video data and possibly other data over single channels. The figure is a block diagram of the multiplexer as configured to process data received via three fiber-optic channels like those of the International Space Station and one electrical-cable channel that conforms to the Institute of Electrical and Electronic Engineers (IEEE) 1394 standard. (This standard consists of specifications of a high-speed serial data interface, the physical layer of which includes a cable known in the art as "FireWire." An IEEE 1394 interface can also transfer power between the components to which it is connected.) The fiber-optic channels carry packet and/or bit-stream signals that conform to the standards of the Consultative Committee for Space Data Systems (CCSDS). The IEEE 1394 interface accepts an isochronous signal like that from a digital camcorder or a video tape recorder. The processing of the four input data streams to combine them into one output stream is governed by a statistical multiplexing algorithm that features a flow-control capability and makes it possible to utilize the transmission channel with nearly 100-percent efficiency. This algorithm allocates the available bandwidth of the transmission channel to the data streams according to a combination of data rates and preassigned priorities. Incoming data streams that demand too much bandwidth are blocked. Bandwidth not needed for a transmission of a given data stream is allocated to other streams as available. Priority is given to the IEEE 1394 stream. In addition to the four incoming data streams, the multiplexer transmits data on the status of the system. An operator can monitor and control the multiplexer via displays and controls on the multiplexer housing. The output of the multiplexer is connected via a coaxial cable with an impedance of 50 Ohms to an interface circuit compatible with the space-shuttle high-speed digital downlink, which operates at a rate of 48 Mb/s.

Holland, Douglas↗
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 NTRS2015

NASA Near Earth Network (NEN), Deep Space Network (DSN) and Space Network (SN) Support of CubeSat Communications

There has been a historical trend to increase capability and drive down the Size, Weight and Power (SWAP) of satellites and that trend continues today. Small satellites, including systems conforming to the CubeSat specification, because of their low launch and development costs, are enabling new concepts and capabilities for science investigations across multiple fields of interest to NASA. NASA scientists and engineers across many of NASAs Mission Directorates and Centers are developing exciting CubeSat concepts and welcome potential partnerships for CubeSat endeavors. From a communications and tracking point of view, small satellites including CubeSats are a challenge to coordinate because of existing small spacecraft constraints, such as limited SWAP and attitude control, low power, and the potential for high numbers of operational spacecraft. The NASA Space Communications and Navigation (SCaN) Programs Near Earth Network (NEN), Deep Space Network (DSN) and the Space Network (SN) are customer driven organizations that provide comprehensive communications services for space assets including data transport between a missions orbiting satellite and its Mission Operations Center (MOC). The NASA NEN consists of multiple ground antennas. The SN consists of a constellation of geosynchronous (Earth orbiting) relay satellites, named the Tracking and Data Relay Satellite System (TDRSS). The DSN currently makes available 13 antennas at its three tracking stations located around the world for interplanetary communication. The presentation will analyze how well these space communication networks are positioned to support the emerging small satellite and CubeSat market. Recognizing the potential support, the presentation will review the basic capabilities of the NEN, DSN and SN in the context of small satellites and will present information about NEN, DSN and SN-compatible flight radios and antenna development activities at the Goddard Space Flight Center (GSFC) and across industry. The presentation will review concepts on how the SN multiple access capability could help locate CubeSats and provide a low-latency early warning system. The presentation will also present how the DSN is evolving to maximize use of its assets for interplanetary CubeSats. The critical spectrum-related topics of available and appropriate frequency bands, licensing, and coordination will be reviewed. Other key considerations, such as standardization of radio frequency interfaces and flight and ground communications hardware systems, will be addressed as such standardization may reduce the amount of time and cost required to obtain frequency authorization and perform compatibility and end-to-end testing. Examples of standardization that exist today are the NASA NEN, DSN and SN systems which have published users guides and defined frequency bands for high data rate communication, as well as conformance to CCSDS standards. The workshop session will also seek input from the workshop participants to better understand the needs of small satellite systems and to identify key development activities and operational approaches necessary to enhance communication and navigation support using NASA's NEN, DSN and SN.

Telecommunication↗