SEARCH · Search NASA

Results for “Command and data handling”

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.

SourceResearch connectionFrom yearThrough year

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

At least 217 records · Page 12

All sources NASA NTRS DOE OSTI

NASA NTRS1998

An Object-Oriented Interface to the CCSDS Ground Telecommand Services

The Telecommand Data Routing and Channel Services defined by the Consultative Committee for Space Data Systems (CCSDS) are flexible enough to support a myriad of commanding models. Because the standard is so broad, the traditional approach has been to implement only the portion of the standard needed by the particular spacecraft being tested/operated. Tasked with providing Telecommand Services for an entire class of spacecraft, where each spacecraft may choose any valid CCSDS commanding model, NASA Code 584 designed a common architecture capable of handling the full CCSDS protocol. The solution uses another CCSDS standard - the Standard Formatted Data Unit (SFDU) as the interface to the Telecommand Services. SFDUs provide a consistent way of labelling data objects, as well as allowing data objects to encapsulate other data objects. The resulting interface is: - Flexible: The full Data Routing and Channel Services are available via a single interface. The client (i.e. the command source) may enter commands at any layer within the protocol stack, specify any of the data aggregation or segmentation methods, and dynamically set any configuration parameter defined in the standard. - Object-oriented: Each object specifies both the data and the actions to be performed with the data. An object may contain other objects. - Expandable: New capabilities are added by defining new objects. Objects pass thru the protocol layers until they reach the applicable layer. The resulting design is: - Modular: The logic for each protocol layer is contained in a separate Application Program Interface (API). The objects used for the external interface are also used for communication between layers. - Distributable: The design can be split along any layer boundary for distribution across multiple machines. The objects ensure data consistency across platforms. This paper describes the SFDU-based interface and the resulting protocol implementation. The implementation is currently used by NASA (National Aeronautics and Space Administration) for integration & test of the microwave Anisotropy Probe (MAP) and Earth observer-I (EO-l) spacecraft. It will be used for post-launch operations of these spacecraft as well as the Imager for Magnetopause to Aurora Global Exploration (IMAGE) spacecraft.

Ray, Timothy Joseph↗

NASA NTRS1976

Flight test evaluation of a separate surface attitude command control system on a Beech 99 airplane

A joint NASA/university/industry program was conducted to flight evaluate a potentially low cost separate surface implementation of attitude command in a Beech 99 airplane. Saturation of the separate surfaces was the primary cause of many problems during development. Six experienced professional pilots who made simulated instrument flight evaluations experienced improvements in airplane handling qualities in the presence of turbulence and a reduction in pilot workload. For ride quality, quantitative data show that the attitude command control system results in all cases of airplane motion being removed from the uncomfortable ride region.

Gee, S. W.↗

NASA NTRS1994

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗

NASA NTRS1990

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

NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket and the Orion capsule, designed to take humans back to the moon in 2024, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the launch. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The messaging software of LCS is responsible for handling the various data types that can be sent between the hardware and software components of the LCS. Since this system is interacting with numerous devices, controllers, and viewports in real time, the distribution of data across the system must be fast, but also reliable and accurate. To verify the accuracy and reliability of the system, developers on the project have created a set of tests to be performed that covers all operations allowed by the system. Given the extensive Application Programming Interface(API) provided by the messaging software, these unit tests are rather time-consuming and costly (in terms of man-hours) to perform. Therefore, an automated testing framework is used to perform supplemental tests automatically when updates are made to the code base.

Rebecca McFadden↗

NASA NTRS1992

Effects of cockpit lateral stick characteristics on handling qualities and pilot dynamics

This report presents the results of analysis of cockpit lateral control feel-system studies. Variations in feel-system natural frequency, damping, and command sensing reference (force and position) were investigated, in combination with variations in the aircraft response characteristics. The primary data for the report were obtained from a flight investigation conducted with a variable-stability airplane, with additional information taken from other flight experiments and ground-based simulations for both airplanes and helicopters . The study consisted of analysis of handling qualities ratings and extraction of open-loop, pilot-vehicle describing functions from sum-of-sines tracking data, including, for a limited subset of these data, the development of pilot models. The study confirms the findings of other investigators that the effects on pilot opinion of cockpit feel-system dynamics are not equivalent to a comparable level of added time delay, and until a more comprehensive set of criteria are developed, it is recommended that feel-system dynamics be considered a delay-inducing element in the aircraft response. The best correlation with time-delay requirements was found when the feel-system dynamics were included in the delay measurements, regardless of the command reference. This is a radical departure from past approaches.

Mitchell, David G.↗

NASA NTRS1972

Information management system breadboard data acquisition and control system.

Description of a breadboard configuration of an advanced information management system based on requirements for high data rates and local and centralized computation for subsystems and experiments to be housed on a space station. The system is to contain a 10-megabit-per-second digital data bus, remote terminals with preprocessor capabilities, and a central multiprocessor. A concept definition is presented for the data acquisition and control system breadboard, and a detailed account is given of the operation of the bus control unit, the bus itself, and the remote acquisition and control unit. The data bus control unit is capable of operating under control of both its own test panel and the test processor. In either mode it is capable of both single- and multiple-message operation in that it can accept a block of data requests or update commands for transmission to the remote acquisition and control unit, which in turn is capable of three levels of data-handling complexity.

Mallary, W. E.↗

NASA NTRS1988

Solutions to time variant problems of real-time expert systems

Real-time expert systems for monitoring and control are driven by input data which changes with time. One of the subtle problems of this field is the propagation of time variant problems from rule to rule. This propagation problem is even complicated under a multiprogramming environment where the expert system may issue test commands to the system to get data and to access time consuming devices to retrieve data for concurrent reasoning. Two approaches are used to handle the flood of input data. Snapshots can be taken to freeze the system from time to time. The expert system treats the system as a stationary one and traces changes by comparing consecutive snapshots. In the other approach, when an input is available, the rules associated with it are evaluated. For both approaches, if the premise condition of a fired rule is changed to being false, the downstream rules should be deactivated. If the status change is due to disappearance of a transient problem, actions taken by the fired downstream rules which are no longer true may need to be undone. If a downstream rule is being evaluated, it should not be fired. Three mechanisms for solving this problem are discussed: tracing, backward checking, and censor setting. In the forward tracing mechanism, when the premise conditions of a fired rule become false, the premise conditions of downstream rules which have been fired or are being evaluated due to the firing of that rule are reevaluated. A tree with its root at the rule being deactivated is traversed. In the backward checking mechanism, when a rule is being fired, the expert system checks back on the premise conditions of the upstream rules that result in evaluation of the rule to see whether it should be fired. The root of the tree being traversed is the rule being fired. In the censor setting mechanism, when a rule is to be evaluated, a censor is constructed based on the premise conditions of the upstream rules and the censor is evaluated just before the rule is fired. Unlike the backward checking mechanism, this one does not search the upstream rules. This paper explores the details of implementation of the three mechanisms.

Yeh, Show-Way↗

NASA NTRS1992

Programmability in AIPS++

AIPS++ is an Astronomical Information Processing System being designed and implemented by an international consortium of NRAO and six other radio astronomy institutions in Australia, India, the Netherlands, the United Kingdom, Canada, and the USA. AIPS++ is intended to replace the functionality of AIPS, to be more easily programmable, and will be implemented in C++ using object-oriented techniques. Programmability in AIPS++ is planned at three levels. The first level will be that of a command-line interpreter with characteristics similar to IDL and PV-Wave, but with an intensive set of operations appropriate to telescope data handling, image formation, and image processing. The third level will be in C++ with extensive use of class libraries for both basic operations and advanced applications. The third level will allow input and output of data between external FORTRAN programs and AIPS++ telescope and image databases. In addition to summarizing the above programmability characteristics, this talk will given an overview of the classes currently being designed for telescope data calibration and editing, image formation, and the 'toolkit' of mathematical 'objects' that will perform most of the processing in AIPS++.

Hjellming, R. M.↗

NASA NTRS1985

Development of an expert system prototype for determining software functional requirements for command management activities at NASA Goddard

The development of an expert system prototype for determining software functional requirements for NASA Goddard's Command Management System (CMS) is described. The role of the CMS is to transform general requests into specific spacecraft commands with command execution conditions. The CMS is part of the NASA Data System which entails the downlink of science and engineering data from NASA near-earth satellites to the user, and the uplink of command and control data to the spacecraft. Subjects covered include: the problem environment of determining CMS software functional requirements; the expert system approach for handling CMS requirements development; validation and evaluation procedures for the expert system.

Liebowitz, J.↗

NASA NTRS1985

The handling of data in solar-terrestrial and in planetary physics

The evolution of data handling systems for solar-terrestrial and planetary physics applications is discussed. The main elements of data management systems for scientific satellites are described, including: command and control; data transmission; prioritization of data users; and data reduction and analysis. The design approaches incorporated into the data management systems of the Interplanetary Monitoring Platform (IMP), International Sun Earth Explorer (ISEE), and the Orbiting Geophysical Observatory, (OGO) spacecraft, are discussed. Emphasis is given to classical, centralized, and hybrid system designs. The report of the Committee on Data Management and Computation (CODMAC) concerning concepts for new data management systems is briefly summarized.

Vette, J. I.↗

NASA NTRS2005

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↗

NASA NTRS2013

Plant Habitat Telemetry / Command Interface and E-MIST

Plant Habitat (PH) is an experiment to be taken to the International Space Station (ISS) in 2016. It is critical that ground support computers have the ability to uplink commands to control PH, and that ISS computers have the ability to downlink PH telemetry data to ground support. This necessitates communication software that can send, receive, and process, PH specific commands and telemetry. The objective of the Plant Habitat Telemetry/ Command Interface is to provide this communication software, and to couple it with an intuitive Graphical User Interface (GUI). Initial investigation of the project objective led to the decision that code be written in C++ because of its compatibility with existing source code infrastructures and robustness. Further investigation led to a determination that multiple Ethernet packet structures would need to be created to effectively transmit data. Setting a standard for packet structures would allow us to distinguish these packets that would range from command type packets to sub categories of telemetry packets. In order to handle this range of packet types, the conclusion was made to take an object-oriented programming approach which complemented our decision to use the C++ programming language. In addition, extensive utilization of port programming concepts was required to implement the core functionality of the communication software. Also, a concrete understanding of a packet processing software was required in order to put aU the components of ISS-to-Ground Support Equipment (GSE) communication together and complete the objective. A second project discussed in this paper is Exposing Microbes to the Stratosphere (EMIST). This project exposes microbes into the stratosphere to observe how they are impacted by atmospheric effects. This paper focuses on the electrical and software expectations of the project, specifically drafting the printed circuit board, and programming the on-board sensors. The Eagle Computer-Aided Drafting (CAD) software was used to draft the E-MIST circuit. This required several component libraries to be created. Coding the sensors and obtaining sensor data involved using the Arduino Uno developmental board and coding language, and properly wiring peripheral sensors to the microcontroller (the central control unit of the experiment).

Walker, Uriae M.↗

DOE OSTI2023

IRIS-DMEM: Efficient Memory Management for Heterogeneous Computing

This paper proposes an efficient data memory management approach for the Intelligent RuntIme System (IRIS) heterogeneous computing framework along with new data transfer policies. IRIS provides a task-based programming model for extreme heterogeneous computing (e.g., CPU, GPU, DSP, FPGA) with support for today's most important programming languages (e.g., OpenMP, OpenCL, CUDA, HIP, OpenACC). However, the IRIS framework either forces the programmer to introduce data transfer commands for each task or relies on suboptimal memory management for automatic and transparent data transfers. The work described here extends IRIS with novel heterogeneous memory handling and introduces novel data transfer policies by employing the Distributed data MEMory handler (DMEM) for efficient and optimal movement of data among the various computing resources. The proposed approach achieves performance gains of up to 7× for tiled LU factorization and tiled DGEMM (i.e., matrix multiplication) benchmarks. Moreover, this approach also reduces data transfers by up to 71% when compared to previous IRIS heterogeneous memory management handlers. This work compares the performance results of the IRIS framework's novel DMEM with the StarPU runtime and MAGMA math library for GPUs. Experiments show a performance gain of up to 1.95× over StarPU and 2.1× over MAGMA.

Miniskar, Narasinga Rao↗

NASA NTRS1988

The UCR gamma ray telescope data acquisition system

A description is given of an electronics system based on the DEC Falcon SBC-11/23+, which has been designed and built to support a balloon-borne double Compton gamma-ray telescope. The system provides support for commands, data acquisition, data routing and compression, and photomultiplier tube gain control. The software consists of a number of interrupt-driven routines of differing priorities to handle each system task. This includes two circular buffers for onboard processing and bit encoding before transmission of the information to the ground computer. Acquisition of gamma-ray events at rates above the 200-Hz telemetry constraint is easily achieved.

O'Neill, T. J.↗

NASA NTRS1976

General purpose simulation system of the data management system for Space Shuttle mission 18

A simulation program for the flow of data through the Data Management System of Spacelab and Space Shuttle was presented. The science, engineering, command and guidance, navigation and control data were included. The programming language used was General Purpose Simulation System V (OS). The science and engineering data flow was modeled from its origin at the experiments and subsystems to transmission from Space Shuttle. Command data flow was modeled from the point of reception onboard and from the CDMS Control Panel to the experiments and subsystems. The GN&C data flow model handled data between the General Purpose Computer and the experiments and subsystems. Mission 18 was the particular flight chosen for simulation. The general structure of the program is presented, followed by a user's manual. Input data required to make runs are discussed followed by identification of the output statistics. The appendices contain a detailed model configuration, program listing and results.

Bengtson, N. M.↗

NASA NTRS2003

Neural Flight Control System

The Neural Flight Control System (NFCS) was developed to address the need for control systems that can be produced and tested at lower cost, easily adapted to prototype vehicles and for flight systems that can accommodate damaged control surfaces or changes to aircraft stability and control characteristics resulting from failures or accidents. NFCS utilizes on a neural network-based flight control algorithm which automatically compensates for a broad spectrum of unanticipated damage or failures of an aircraft in flight. Pilot stick and rudder pedal inputs are fed into a reference model which produces pitch, roll and yaw rate commands. The reference model frequencies and gains can be set to provide handling quality characteristics suitable for the aircraft of interest. The rate commands are used in conjunction with estimates of the aircraft s stability and control (S&C) derivatives by a simplified Dynamic Inverse controller to produce virtual elevator, aileron and rudder commands. These virtual surface deflection commands are optimally distributed across the aircraft s available control surfaces using linear programming theory. Sensor data is compared with the reference model rate commands to produce an error signal. A Proportional/Integral (PI) error controller "winds up" on the error signal and adds an augmented command to the reference model output with the effect of zeroing the error signal. In order to provide more consistent handling qualities for the pilot, neural networks learn the behavior of the error controller and add in the augmented command before the integrator winds up. In the case of damage sufficient to affect the handling qualities of the aircraft, an Adaptive Critic is utilized to reduce the reference model frequencies and gains to stay within a flyable envelope of the aircraft.

Gundy-Burlet, Karen↗

DOE OSTI2021

A Self-Synchronizing Underwater Acoustic Network for Mooring Load Monitoring of a Wave Energy Converter

This paper reports on the development of a self-synchronizing underwater acoustic network developed for remote monitoring of mooring loads in Wave Energy Converters (WECs). This network uses Time Division Multiple Access and operates self-contained with the ability for users to remotely transmit commands to the network as needed. Each node is a self-contained unit, consisting of a protocol adaptor board, an FAU-DPAM underwater acoustic modem and a battery pack. A node can be connected to a load cell, to a topside user or to the WEC. Every node is swapable. The protocol adaptor board, named Protocol Adaptor for Digital LOad Cell (PADLOC) supports a variety of digital load cell message formats (CAN, MODBUS, custom ASCII) and underwater acoustic modem serial formats. PADLOC enables topside users to connect to separate load cells through a user-specific command. This is especially important if the user is monitoring multiple load cells during deployment or maintenance, when the primary data system may be offline. Each PADLOC board handles formatting, buffering and has a one-on-one serial connection with each pair (node) of a digital load cell and acoustic modem. In addition, each PADLOC board handles the timekeeping and power saving features for each node. The only limitation is the data bit rate and delay limitations associated with the underwater acoustic modem. A four node self-synchronizing network has been developed to demonstrate the load cell monitoring capability using the PADLOC technology on the CalWave WEC.

acoustic↗