Search NASA⌕ Search

SEARCH · Search NASA

Results for “spacecraft command and data handling system”

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 91 records · Page 5

Adapting the SpaceCube v2.0 Data Processing System for Mission-Unique Application Requirements

The SpaceCubeTM v2.0 system is a superior high performance, reconfigurable, hybrid data processing system that can be used in a multitude of applications including those that require a radiation hardened and reliable solution. This paper provides an overview of the design architecture, flexibility, and the advantages of the modular SpaceCube v2.0 high performance data processing system for space applications. The current state of the proven SpaceCube technology is based on nine years of engineering and operations. Five systems have been successfully operated in space starting in 2008 with four more to be delivered for launch vehicle integration in 2015. The SpaceCube v2.0 system is also baselined as the avionics solution for five additional flight projects and is always a top consideration as the core avionics for new instruments or spacecraft control. This paper will highlight how this multipurpose system is currently being used to solve design challenges of three independent applications. The SpaceCube hardware adapts to new system requirements by allowing for application-unique interface cards that are utilized by reconfiguring the underlying programmable elements on the core processor card. We will show how this system is being used to improve on a heritage NASA GPS technology, enable a cutting-edge LiDAR instrument, and serve as a typical command and data handling (CDH) computer for a space robotics technology demonstration.

Xilinx FPGA↗

Aquarius' Object-Oriented, Plug and Play Component-Based Flight Software

The Aquarius mission involves a combined radiometer and radar instrument in low-Earth orbit, providing monthly global maps of Sea Surface Salinity. Operating successfully in orbit since June, 2011, the spacecraft bus was furnished by the Argentine space agency, Comision Nacional de Actividades Espaciales (CONAE). The instrument, built jointly by NASA's Caltech/JPL and Goddard Space Flight Center, has been successfully producing expectation-exceeding data since it was powered on in August of 2011. In addition to the radiometer and scatterometer, the instrument contains an command & data-handling subsystem with a computer and flight software (FSW) that is responsible for managing the instrument, its operation, and its data. Aquarius' FSW is conceived and architected as a Component-based system, in which the running software consists of a set of Components, each playing a distinctive role in the subsystem, instantiated and connected together at runtime. Component architectures feature a well-defined set of interfaces between the Components, visible and analyzable at the architectural level (see [1]). As we will describe, this kind of an architecture offers significant advantages over more traditional FSW architectures, which often feature a monolithic runtime structure. Component-based software is enabled by Object-Oriented (OO) techniques and languages, the use of which again is not typical in space mission FSW. We will argue in this paper that the use of OO design methods and tools (especially the Unified Modeling Language), as well as the judicious usage of C++, are very well suited to FSW applications, and we will present Aquarius FSW, describing our methods, processes, and design, as a successful case in point.

Component Architecture↗

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

Parallel processing spacecraft communication system

An uplink controlling assembly speeds data processing using a special parallel codeblock technique. A correct start sequence initiates processing of a frame. Two possible start sequences can be used; and the one which is used determines whether data polarity is inverted or non-inverted. Processing continues until uncorrectable errors are found. The frame ends by intentionally sending a block with an uncorrectable error. Each of the codeblocks in the frame has a channel ID. Each channel ID can be separately processed in parallel. This obviates the problem of waiting for error correction processing. If that channel number is zero, however, it indicates that the frame of data represents a critical command only. That data is handled in a special way, independent of the software. Otherwise, the processed data further handled using special double buffering techniques to avoid problems from overrun. When overrun does occur, the system takes action to lose only the oldest data.

Bolotin, Gary S.↗

Orion Entry Handling Qualities Assessments

The Orion Command Module (CM) is a capsule designed to bring crew back from the International Space Station (ISS), the moon and beyond. The atmospheric entry portion of the flight is deigned to be flown in autopilot mode for nominal situations. However, there exists the possibility for the crew to take over manual control in off-nominal situations. In these instances, the spacecraft must meet specific handling qualities criteria. To address these criteria two separate assessments of the Orion CM s entry Handling Qualities (HQ) were conducted at NASA s Johnson Space Center (JSC) using the Cooper-Harper scale (Cooper & Harper, 1969). These assessments were conducted in the summers of 2008 and 2010 using the Advanced NASA Technology Architecture for Exploration Studies (ANTARES) six degree of freedom, high fidelity Guidance, Navigation, and Control (GN&C) simulation. This paper will address the specifics of the handling qualities criteria, the vehicle configuration, the scenarios flown, the simulation background and setup, crew interfaces and displays, piloting techniques, ratings and crew comments, pre- and post-fight briefings, lessons learned and changes made to improve the overall system performance. The data collection tools, methods, data reduction and output reports will also be discussed. The objective of the 2008 entry HQ assessment was to evaluate the handling qualities of the CM during a lunar skip return. A lunar skip entry case was selected because it was considered the most demanding of all bank control scenarios. Even though skip entry is not planned to be flown manually, it was hypothesized that if a pilot could fly the harder skip entry case, then they could also fly a simpler loads managed or ballistic (constant bank rate command) entry scenario. In addition, with the evaluation set-up of multiple tasks within the entry case, handling qualities ratings collected in the evaluation could be used to assess other scenarios such as the constant bank angle maintenance case. The 2008 entry assessment was divided into two sections (see Figure 1). Entry I was the first, high speed portion of a lunar return and Entry II was the second, lower speed portion of a lunar return, which is similar (but not identical) to a typical ISS return.

Bihari, B.↗

The Space Telescope SI C&DH system

The Hubble Space Telescope Scientific Instrument Control and Data Handling Subsystem (SI C&DH) is designed to interface with five scientific instruments of the Space Telescope to provide ground and autonomous control and collect health and status information using the Standard Telemetry and Command Components (STACC) multiplex data bus. It also formats high throughput science data into packets. The packetized data is interleaved and Reed-Solomon encoded for error correction and Pseudo Random encoded. An inner convolutional coding with the outer Reed-Solomon coding provides excellent error correction capability. The subsystem is designed with the capacity for orbital replacement in order to meet a mission life of fifteen years. The spacecraft computer and the SI C&DH computer coordinate the activities of the spacecraft and the scientific instruments to achieve the mission objectives.

Gadwal, Govind R.↗

Support for User Interfaces for Distributed Systems

An extensible Java(TradeMark) software framework supports the construction and operation of graphical user interfaces (GUIs) for distributed computing systems typified by ground control systems that send commands to, and receive telemetric data from, spacecraft. Heretofore, such GUIs have been custom built for each new system at considerable expense. In contrast, the present framework affords generic capabilities that can be shared by different distributed systems. Dynamic class loading, reflection, and other run-time capabilities of the Java language and JavaBeans component architecture enable the creation of a GUI for each new distributed computing system with a minimum of custom effort. By use of this framework, GUI components in control panels and menus can send commands to a particular distributed system with a minimum of system-specific code. The framework receives, decodes, processes, and displays telemetry data; custom telemetry data handling can be added for a particular system. The framework supports saving and later restoration of users configurations of control panels and telemetry displays with a minimum of effort in writing system-specific code. GUIs constructed within this framework can be deployed in any operating system with a Java run-time environment, without recompilation or code changes.

Eychaner, Glenn↗

Flow Measurement

Macrodyne, Inc.'s laser velocimeter (LV) is a system used in wind tunnel testing of aircraft, missiles and spacecraft employing electro optical techniques to probe the flow field as the tunnel blows air over a model of flight vehicle and to determine velocity of air and its direction at many points around the model. However, current state-of-the-art minicomputers cannot handle the massive flow of real time data from several sources simultaneously. Langley developed instrument Laser Velocimeter Autocovariance Buffer Interface (LVABI). LVABI is interconnecting instrument between LV and computer. It acquires data from as many as six LV channels at high real time data rates, stores it in memory and sends it to computer on command. LVABI has application in variety of research, industrial and defense functions requiring precise flow measurement.

Source record↗

Lunar Reconnaissance Orbiter (LRO) Command and Data Handling Flight Electronics Subsystem

A document describes a high-performance, modular, and state-of-the-art Command and Data Handling (C&DH) system developed for use on the Lunar Reconnaissance Orbiter (LRO) mission. This system implements a complete hardware C&DH subsystem in a single chassis enclosure that includes a processor card, 48 Gbytes of solid-state recorder memory, data buses including MIL-STD-1553B, custom RS-422, SpaceWire, analog collection, switched power services, and interfaces to the Ka-Band and S-Band RF communications systems. The C&DH team capitalized on extensive experience with hardware and software with PCI bus design, SpaceWire networking, Actel FPGA design, digital flight design techniques, and the use of VxWorks for the real-time operating system. The resulting hardware architecture was implemented to meet the LRO mission requirements. The C&DH comprises an enclosure, a backplane, a low-voltage power converter, a single-board computer, a communications interface board, four data storage boards, a housekeeping and digital input/output board, and an analog data acquisition board. The interfaces between the C&DH and the instruments and avionics are connected through a SpaceWire network, a MIL-STD-1553 bus, and a combination of synchronous and asynchronous serial data transfers over RS-422 and LVDS (low-voltage differential-signaling) electrical interfaces. The C&DH acts as the spacecraft data system with an instrument data manager providing all software and internal bus scheduling, ingestion of science data, distribution of commands, and performing science operations in real time.

Nguyen, Quang↗

Autonomous Satellite Command and Control through the World Wide Web: Phase 3

NASA's New Millenium Program (NMP) has identified a variety of revolutionary technologies that will support orders of magnitude improvements in the capabilities of spacecraft missions. This program's Autonomy team has focused on science and engineering automation technologies. In doing so, it has established a clear development roadmap specifying the experiments and demonstrations required to mature these technologies. The primary developmental thrusts of this roadmap are in the areas of remote agents, PI/operator interface, planning/scheduling fault management, and smart execution architectures. Phases 1 and 2 of the ASSET Project (previously known as the WebSat project) have focused on establishing World Wide Web-based commanding and telemetry services as an advanced means of interfacing a spacecraft system with the PI and operators. Current automated capabilities include Web-based command submission, limited contact scheduling, command list generation and transfer to the ground station, spacecraft support for demonstrations experiments, data transfer from the ground station back to the ASSET system, data archiving, and Web-based telemetry distribution. Phase 2 was finished in December 1996. During January-December 1997 work was commenced on Phase 3 of the ASSET Project. Phase 3 is the subject of this report. This phase permitted SSDL and its project partners to expand the ASSET system in a variety of ways. These added capabilities included the advancement of ground station capabilities, the adaptation of spacecraft on-board software, and the expansion of capabilities of the ASSET management algorithms. Specific goals of Phase 3 were: (1) Extend Web-based goal-level commanding for both the payload PI and the spacecraft engineer; (2) Support prioritized handling of multiple PIs as well as associated payload experimenters; (3) Expand the number and types of experiments supported by the ASSET system and its associated spacecraft; (4) Implement more advanced resource management, modeling and fault management capabilities that integrate the space and ground segments of the space system hardware; (5) Implement a beacon monitoring test; (6) Implement an experimental blackboard controller for space system management; (7) Further define typical ground station developments required for Internet-based remote control and for full system automation of the PI-to-spacecraft link. Each of those goals is examined in the next section. Significant sections of this report were also published as a conference paper.

Cantwell, Brian↗

Automated Commanding of the SMAP Spacecraft Enables Efficient, Reliable, and Responsive Operations

The Soil Moisture Active Passive (SMAP) mission developed and deployed a system to autonomously handle most routine commanding of the observatory. This system of ground software is able to build commands, validate them, and radiate the commands to the spacecraft, all without human interaction. In the case of an off -nominal scenario, the system will abort gracefully and notify the mission operations team of the problem. The system was phased into operations during the first three months of the SMAP mission and handles over 90% of the weekly commanding of the vehicle. The gradual introduction of the automation in flight, along with an extensive test campaign, was instrumental in the success of the software. The automation has enabled substantial efficiencies in operations team staffing and has improved reliability by removing the potential for human error. The system also allows the SMAP project to be more responsive which has shown significant benefits in areas of data latency and science accuracy.

automation↗

Secure Web-based Ground System User Interfaces over the Open Internet

A prototype has been developed which makes use of commercially available products in conjunction with the Java programming language to provide a secure user interface for command and control over the open Internet. This paper reports successful demonstration of: (1) Security over the Internet, including encryption and certification; (2) Integration of Java applets with a COTS command and control product; (3) Remote spacecraft commanding using the Internet. The Java-based Spacecraft Web Interface to Telemetry and Command Handling (Jswitch) ground system prototype provides these capabilities. This activity demonstrates the use and integration of current technologies to enable a spacecraft engineer or flight operator to monitor and control a spacecraft from a user interface communicating over the open Internet using standard World Wide Web (WWW) protocols and commercial off-the-shelf (COTS) products. The core command and control functions are provided by the COTS Epoch 2000 product. The standard WWW tools and browsers are used in conjunction with the Java programming technology. Security is provided with the current encryption and certification technology. This system prototype is a step in the direction of giving scientist and flight operators Web-based access to instrument, payload, and spacecraft data.

Langston, James H.↗

Practical Application of PRA as an Integrated Design Tool for Space Systems

This paper presents the application of the first comprehensive Probabilistic Risk Assessment (PRA) during the design phase of a joint NASA/NOAA weather satellite program, Geostationary Operational Environmental Satellite Series R (GOES-R). GOES-R is the next generation weather satellite primarily to help understand the weather and help save human lives. PRA has been used at NASA for Human Space Flight for many years. PRA was initially adopted and implemented in the operational phase of manned space flight programs and more recently for the next generation human space systems. Since its first use at NASA, PRA has become recognized throughout the Agency as a method of assessing complex mission risks as part of an overall approach to assuring safety and mission success throughout project lifecycles. PRA is now included as a requirement during the design phase of both NASA next generation manned space vehicles as well as for high priority robotic missions. The influence of PRA on GOES-R design and operation concepts are discussed in detail. The GOES-R PRA is unique at NASA for its early implementation. It also represents a pioneering effort to integrate risks from both Spacecraft (SC) and Ground Segment (GS) to fully assess the probability of achieving mission objectives. PRA analysts were actively involved in system engineering and design engineering to ensure that a comprehensive set of technical risks were correctly identified and properly understood from a design and operations perspective. The analysis included an assessment of SC hardware and software, SC fault management system, GS hardware and software, common cause failures, human error, natural hazards, solar weather and infrastructure (such as network and telecommunications failures, fire). PRA findings directly resulted in design changes to reduce SC risk from micro-meteoroids. PRA results also led to design changes in several SC subsystems, e.g. propulsion, guidance, navigation and control (GNC), communications, mechanisms, and command and data handling (C&DH). The fault tree approach assisted in the development of the fault management system design. Human error analysis, which examined human response to failure, indicated areas where automation could reduce the overall probability of gaps in operation by half. In addition, the PRA brought to light many potential root causes of system disruptions, including earthquakes, inclement weather, solar storms, blackouts and other extreme conditions not considered in the typical reliability and availability analyses. Ultimately the PRA served to identify potential failures that, when mitigated, resulted in a more robust design, as well as to influence the program's concept of operations. The early and active integration of PRA with system and design engineering provided a well-managed approach for risk assessment that increased reliability and availability, optimized lifecyc1e costs, and unified the SC and GS developments.

Kalia, Prince↗

Development of a 13 kW Hall Thruster Propulsion System Performance Model for AEPS

The Advanced Electric Propulsion System (AEPS) program will develop a flight 13kW Hall thruster propulsion system based on NASA's HERMeS thruster. The AEPS system includes the Hall Thruster, the Power Processing Unit (PPU) and the Xenon Flow Controller (XFC). These three primary components must operate together to ensure that the system generates the required combinations of thrust and specific impulse at the required system efficiencies for the desired system lifetime. At the highest level, the AEPS system will be integrated into the spacecraft and will receive power, propellant, and commands from the spacecraft. Power and propellant flow rates will be determined by the throttle set points commanded by the spacecraft. Within the system, the major control loop is between the mass flow rate and thruster current, with time-dependencies required to handle all expected transients, and additional, much slower interactions between the thruster and cathode temperatures, flow controller and PPU. The internal system interactions generally occur on shorter timescales than the spacecraft interactions, though certain failure modes may require rapid responses from the spacecraft. The AEPS system performance model is designed to account for all these interactions in a way that allows evaluation of the sensitivity of the system to expected changes over the planned mission as well as to assess the impacts of normal component and assembly variability during the production phase of the program. This effort describes the plan for the system performance model development, correlation to NASA test data, and how the model will be used to evaluate the critical internal and external interactions. The results will ensure the component requirements do not unnecessarily drive the system cost or overly constrain the development program. Finally, the model will be available to quickly troubleshoot any future unforeseen development challenges.

Stanley, Steven↗

The Telestation: A product for distributed data gathering and operations

Advances in computer, navigation and wireless telecommunication technologies are enabling better electronic devices at reduced costs. Individually, these devices have been applied to increase the performance of many common systems, such as desktop computers, surveying equipment, and modems. However, we believe the convergence of these three technologies will create a product that simultaneously lowers life cycle costs while increasing operational effectiveness. Space Systems/Loral (SS/L) is developing portions of this product, known as the Telestation, for both terrestrial and orbital applications. The Telestation consists of an advanced microprocessor for command and data handling; a GPS receiver for position, time, and attitude information; and a Globalstar Transceiver for two-way digital communications. The Telestation provides the user with real-time command and control of globally distributed hardware elements. This capability can be applied terrestrially for gathering information (e.g., science, environmental, etc.) in remote or inhospitable locations, or where logistical support is inadequate. An in-orbit version can be used for spacecraft or payload operations, allowing principal investigators instant access to their payloads during all phases of a mission. This paper describes some cost effectiveness metrics of the Telestation, its development status, and its utility in both terrestrial and orbital applications.

Cleave, Robert R.↗

The electronic switching spherical array antenna for the Earth Radiation Budget Spacecraft

The ESSA is a microprocessor-controlled antenna for low orbiting spacecraft for telemetry and command relay through the Tracking and Data Relay Satellite System (TDRSS). The array is a hemispherical shape covered with disk radiating elements. A group of radiating elements are continuously selected by the microprocessor controller to form a beam in the direction of a TDRS. A radial switching power divider uses PIN diodes to select the desired radiating elements. The antenna gain is a function of the size of the hemispherical dome. A 30-inch diameter dome is presently being built for the Earth Radiation Budget Spacecraft (ERBS). Gain of this antenna over a hemisphere is 14 dBi and polarization is lefthand circular. There are 145 radiating elements with 12 being used at one time to form a beam. The ESSA subsystem weights 74 pounds and power consumption is 20 watts. RF power handling capability is 30 watts. The S-Band radiating elements have a 10 percent bandwidth that allows simultaneous transmission and reception.

Kudrna, K.↗

Surveyor Project Final Report: Part 1 - Project Description and Performance, Volume 1

The Surveyor Project planned and conducted seven unmanned lunar missions for which spacecraft were launched between May 1966 and January 1968. Each of the spacecraft was successfully launched with the then newly developed Atlas/Centaur vehicle which utilized for the first time a high-specific-impulse, liquid hydrogen/liquid oxygen fueled stage. Five of the spacecraft successfully soft-landed and returned a great quantity of engineering and scientific data on extensive postlanding operations, accomplishing all mission and project objectives. Four of the spacecraft soft-landed at selected mare sites to provide data which were required to support the Apollo Program. The final spacecraft was then successfully used for scientific investigation of a contrasting site in the rugged lunar highlands. Surveyor was a fully attitude-stabilized spacecraft designed to receive and execute a wide variety of earth commands, as well as to perform certain automatic functions including the critical terminal-descent and soft-landing sequences. Significant new and advanced subsystems that were developed and/or used in combination to enable Surveyor to execute the complex terminal phase of flight were: (1) a solid-propellant main retro motor, (2) throttlable liquid-propellant vernier engines (also used for midcourse velocity correction), (3) highly sensitive velocity- and altitude-sensing radars, and (4) an automatic closed-loop guidance and control system. The first Surveyor spacecraft carried a survey television camera which, together with other engineering instrumentation, obtained in-flight and postlanding data. The complement of instruments carried on later missions included various combinations of the following additional devices: (1) a soil mechanics/surface sampler instrument for picking, digging, and handling lunar surface material; (2) an alpha scattering instrument for performing a chemical analysis of the lunar surface material; and (3) magnets attached to the spacecraft for determining magnetic properties of the soil.

Jet Propulsion Laboratory↗

Surveyor Project Final Report: Part 1 - Project Description and Performance, Volume 2

The Surveyor Project planned and conducted seven unmanned lunar missions for which spacecraft were launched between May 1966 and January 1968. Each of the spacecraft was successfully launched with the then newly developed Atlas/Centaur vehicle which utilized for the first time a high-specific-impulse, liquid hydrogen/liquid oxygen fueled stage. Five of the spacecraft successfully soft-landed and returned a great quantity of engineering and scientific data on extensive postlanding operations, accomplishing all mission and project objectives. Four of the spacecraft soft-landed at selected mare sites to provide data which were required to support the Apollo Program. The final spacecraft was then successfully used for scientific investigation of a contrasting site in the rugged lunar highlands. Surveyor was a fully attitude-stabilized spacecraft designed to receive and execute a wide variety of earth commands, as well as to perform certain automatic functions including the critical terminal-descent and soft-landing sequences. Significant new and advanced subsystems that were developed and/or used in combination to enable Surveyor to execute the complex terminal phase of flight were: (1) a solid-propellant main retro motor, (2) throttlable liquid-propellant vernier engines (also used for midcourse velocity correction), (3) highly sensitive velocity- and altitude-sensing radars, and (4) an automatic closed-loop guidance and control system. The first Surveyor spacecraft carried a survey television camera which, together with other engineering instrumentation, obtained in-flight and postlanding data. The complement of instruments carried on later missions included various combinations of the following additional devices: (1) a soil mechanics/surface sampler instrument for picking, digging, and handling lunar surface material; (2) an alpha scattering instrument for performing a chemical analysis of the lunar surface material; and (3) magnets attached to the spacecraft for determining magnetic properties of the soil.

Jet Propulsion Laboratory↗