Search NASA⌕ Search

SEARCH · Search NASA

Results for “command process”

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 433 records · Page 24
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

DYNACLIPS (DYNAmic CLIPS): A dynamic knowledge exchange tool for intelligent agents

In a dynamic environment, intelligent agents must be responsive to unanticipated conditions. When such conditions occur, an intelligent agent may have to stop a previously planned and scheduled course of actions and replan, reschedule, start new activities and initiate a new problem solving process to successfully respond to the new conditions. Problems occur when an intelligent agent does not have enough knowledge to properly respond to the new situation. DYNACLIPS is an implementation of a framework for dynamic knowledge exchange among intelligent agents. Each intelligent agent is a CLIPS shell and runs a separate process under SunOS operating system. Intelligent agents can exchange facts, rules, and CLIPS commands at run time. Knowledge exchange among intelligent agents at run times does not effect execution of either sender and receiver intelligent agent. Intelligent agents can keep the knowledge temporarily or permanently. In other words, knowledge exchange among intelligent agents would allow for a form of learning to be accomplished.

Cengeloglu, Yilmaz↗
NASA NTRS2001

Gamma Ray Large Area Space Telescope (GLAST) Balloon Flight Engineering Model: Overview

The Gamma Ray Large Area Space Telescope (GLAST) Large Area Telescope (LAT) is a pair-production high-energy (greater than 20 MeV) gamma-ray telescope being built by an international partnership of astrophysicists and particle physicists for a satellite launch in 2006, designed to study a wide variety of high-energy astrophysical phenomena. As part of the development effort, the collaboration has built a Balloon Flight Engineering Model (BFEM) for flight on a high-altitude scientific balloon. The BFEM is approximately the size of one of the 16 GLAST-LAT towers and contains all the components of the full instrument: plastic scintillator anticoincidence system (ACD), high-Z foil/Si strip pair-conversion tracker (TKR), CsI hodoscopic calorimeter (CAL), triggering and data acquisition electronics (DAQ), commanding system, power distribution, telemetry, real-time data display, and ground data processing system. The principal goal of the balloon flight was to demonstrate the performance of this instrument configuration under conditions similar to those expected in orbit. Results from a balloon flight from Palestine, Texas, on August 4, 2001, show that the BFEM successfully obtained gamma-ray data in this high-background environment.

Thompson, D. J.↗
NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗
NASA NTRS2006

Establishment and Implementation of a Close Approach Evaluation and Avoidance Process for Earth Observing System Missions

In the fall of 2004, the Earth Science Mission Operations Project tasked the Goddard Space Flight Center (GSPC) Flight Dynamics Analysis Branch with establishment of a process to protect the high-value Earth Observing System (EOS) missions (Terra, Aqua, and Aura) from close approaches with space debris and other orbiting objects. An agreement between GSFC and the United States Strategic Command was put in place so that close approach predictions would be routinely generated. This paper describes the ESMO conjunction assessment process for the EOS satellites. Process details, including tools and algorithms developed, are discussed. Particular details for a predicted close approach between Terra and a piece of space debris that resulted in the execution of a debris avoidance maneuver are included. This close approach example is described in detail fiom the first screening identification through execution of the mitigation maneuver to illustrate both the process and lessons learned fiom its implementation.

Newman, Lauri↗
NASA NTRS1986

Generic Ada code in the NASA space station command, control and communications environment

The results of efforts to apply powerful Ada constructs to the formatted message handling process are described. The goal of these efforts was to extend the state-of-technology in message handling while at the same time producing production-quality, reusable code. The first effort was initiated in September, 1984 and delivered in April, 1985. That product, the Generic Message Handling Facility, met initial goals, was reused, and is available in the Ada Repository on ARPANET. However, it became apparent during its development that the initial approach to building a message handler template was not optimal. As a result of this initial effort, several alternate approaches were identified, and research is now on-going to identify an improved product. The ultimate goal is to be able to instantly build a message handling system for any message format given a specification of that message format. The problem lies in how to specify the message format, and one that is done, how to use that information to build the message handler. Message handling systems and message types are described. The initial efforts, its results and its shortcomings are detailed. The approach now being taken to build a system which will be significantly easier to implement, and once implemented, easier to use, is described. Finally, conclusions are offered.

Mcdougall, D. P.↗
NASA NTRS2013

Certification-Based Process Analysis

Space mission architects are often challenged with knowing which investment in technology infusion will have the highest return. Certification-based analysis (CBA) gives architects and technologists a means to communicate the risks and advantages of infusing technologies at various points in a process. Various alternatives can be compared, and requirements based on supporting streamlining or automation can be derived and levied on candidate technologies. CBA is a technique for analyzing a process and identifying potential areas of improvement. The process and analysis products are used to communicate between technologists and architects. Process means any of the standard representations of a production flow; in this case, any individual steps leading to products, which feed into other steps, until the final product is produced at the end. This sort of process is common for space mission operations, where a set of goals is reduced eventually to a fully vetted command sequence to be sent to the spacecraft. Fully vetting a product is synonymous with certification. For some types of products, this is referred to as verification and validation, and for others it is referred to as checking. Fundamentally, certification is the step in the process where one insures that a product works as intended, and contains no flaws.

Knight, Russell L.↗
NASA NTRS1977

Models for interrupted monitoring of a stochastic process

As computers are added to the cockpit, the pilot's job is changing from of manually flying the aircraft, to one of supervising computers which are doing navigation, guidance and energy management calculations as well as automatically flying the aircraft. In this supervisorial role the pilot must divide his attention between monitoring the aircraft's performance and giving commands to the computer. Normative strategies are developed for tasks where the pilot must interrupt his monitoring of a stochastic process in order to attend to other duties. Results are given as to how characteristics of the stochastic process and the other tasks affect the optimal strategies.

Palmer, E.↗
NASA NTRS1985

Automated support requirement system user's guide for nondata entry personnel

ASRS provides the capability to process intercenter/agency support requirements and commitments necessary for support of the Space Shuttle Launch and Landing, Flight, and Cargo operations. The instructions and commands that users will be allowed to utilize are presented. ASRS utilizes a data base stored on Honeywell DPS8 computer. ASRS programs are written in COBOL 74 utilizing the Honeywell DMIV-TP Processing System and the GCOS8 Operating System; they can also be accessed through Telenet or Datanet.

Maryland, J. E., Jr.↗
NASA NTRS2021

Validation of Small Satellite Dynamics Simulation Modules using ASTERIA Flight Data

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a CubeSat space telescope that operated in low-Earth orbit, having been deployed from the International Space Station in 2017. The spacecraft has achieved sub-arcsecond pointing stability and millikelvin thermal stability over 20-minute observations. A key enabling feature of the ASTERIA mission is the low level of pointing error that has been demonstrated under ASTERIA’s fine pointing control mode. Prior to launch, the ASTERIA mission performed analysis and simulations to estimate the in-flight pointing performance. This analysis used reaction wheel models provided by JPL’s Small Satellite Dynamics Testbed (SSDT), which had performed Kistler table testing to characterize the jitter caused by the reaction wheels of the Blue Canyon Technologies XACT attitude control unit within ASTERIA. These models were subsequently incorporated into the SSDT simulation. The main source of jitter, the high-frequency attitude disturbance over the camera exposure time, on ASTERIA is the set of rotating reaction wheels that are used for maintaining fine pointing during observations. The reaction wheels impart disturbance forces and torques continuously that cause unwanted motion during imaging. Increased jitter consequently leads to blurring of the image. Therefore, to benefit all SmallSat missions devoted to photometric or spectroscopic astrophysics applications, an on-orbit flight data acquisition and jitter testing campaign was performed in an attempt to help validate the SSDT’s simulation models. This paper describes the process used to validate several simulation models and attempt to characterize the ASTERIA jitter by analyzing the size of the resulting spot size for the target stars as a function of wheel speed, having commanded four wheel speeds for each of three stars of known brightness. After summarizing the on-orbit observation and jitter level measurement process, this paper compares the results obtained from the flight operational environment to the corresponding set of simulation jitter levels. Though the flight data obtained during this experiment was not sufficient to validate the simulation’s jitter model, other models have been validated with flight data, including the magnetic field, orbit propagation, sun position, and long-duration orbit decay models, which may be used by all other projects that use the SSDT’s simulation to increase system capability knowledge.

Mohan, Swati↗
NASA NTRS1998

A New Image Processing and GIS Package

The image processing and GIS package ELAS was developed during the 1980's by NASA. It proved to be a popular, influential and powerful in the manipulation of digital imagery. Before the advent of PC's it was used by hundreds of institutions, mostly schools. It is the unquestioned, direct progenitor or two commercial GIS remote sensing packages, ERDAS and MapX and influenced others, such as PCI. Its power was demonstrated by its use for work far beyond its original purpose, having worked several different types of medical imagery, photomicrographs of rock, images of turtle flippers and numerous other esoteric imagery. Although development largely stopped in the early 1990's the package still offers as much or more power and flexibility than any other roughly comparable package, public or commercial. It is a huge body or code, representing more than a decade of work by full time, professional programmers. The current versions all have several deficiencies compared to current software standards and usage, notably its strictly command line interface. In order to support their research needs the authors are in the process of fundamentally changing ELAS, and in the process greatly increasing its power, utility, and ease of use. The new software is called ELAS II. This paper discusses the design of ELAS II.

Rickman, D.↗
NASA NTRS2009

Aquarius Digital Processing Unit

Three documents provide information on a digital processing unit (DPU) for the planned Aquarius mission, in which a radiometer aboard a spacecraft orbiting Earth is to measure radiometric temperatures from which data on sea-surface salinity are to be deduced. The DPU is the interface between the radiometer and an instrument-command-and-data system aboard the spacecraft. The DPU cycles the radiometer through a programmable sequence of states, collects and processes all radiometric data, and collects all housekeeping data pertaining to operation of the radiometer. The documents summarize the DPU design, with emphasis on innovative aspects that include mainly the following: a) In the radiometer and the DPU, conversion from analog voltages to digital data is effected by means of asynchronous voltage-to-frequency converters in combination with a frequency-measurement scheme implemented in field-programmable gate arrays (FPGAs). b) A scheme to compensate for aging and changes in the temperature of the DPU in order to provide an overall temperature-measurement accuracy within 0.01 K includes a high-precision, inexpensive DC temperature measurement scheme and a drift-compensation scheme that was used on the Cassini radar system. c) An interface among multiple FPGAs in the DPU guarantees setup and hold times.

Forgione, Joshua↗
NASA NTRS2017

The Cassini Grand Finale Mission: Planning for a New Mission Environment

The Cassini F-Ring & Proximal Orbits (FRPO) is a new and unique mission; to ensure the highest priority science gets implemented, the POST (Proximal Orbit Science Team) was created to pre-allocate the time around periapse for all 22 proximal orbits. The F-ring orbits, and proximal time outside of POST, were handled similar to Cassini’s Solstice Mission using the Pre-Integrated Event (PIE) process. The new and unique properties of the spacecraft’s trajectory required much forethought to be flown safely while still planning for the most and best science return possible. Some ring-plane crossings (RPX) will be protected against dust impacts by turning the high gain antenna (HGA) to the dust RAM direction (HGA2RAM). If on the first proximal RPX higher than expected dust readings are seen then the Project Office may choose to require more (all) subsequent RPX to be HGA2RAM, implemented via a real-time command overlay for uplinked sequences. The pointing uncertainties will be larger than usual after the final targeted flyby; some of the process changes to address this include adding extra orbit trim maneuvers (OTMs) (fuel permitting) to resync to the reference trajectory and reduce pointing uncertainties; and movable blocks of commands to be used for some periapses where atmospheric drag may cause large timing shifts Changes made for FRPO to address perceptions that these sequences will be hard to implement include requiring early pointing designs (during integration) for certain types of observations, requiring teams to check early on that they can turn to and from their observation attitude, and that their attitude is safe, and adjusting the Implementation process to give more time for science observation designers. This paper will discuss these process changes and lessons learned so far.

Ray, Trina↗
NASA NTRS2010

AutoGen Version 5.0

Version 5.0 of the AutoGen software has been released. Previous versions, variously denoted Autogen and autogen, were reported in two articles: Automated Sequence Generation Process and Software (NPO-30746), Software Tech Briefs (Special Supplement to NASA Tech Briefs), September 2007, page 30, and Autogen Version 2.0 (NPO- 41501), NASA Tech Briefs, Vol. 31, No. 10 (October 2007), page 58. To recapitulate: AutoGen (now signifying automatic sequence generation ) automates the generation of sequences of commands in a standard format for uplink to spacecraft. AutoGen requires fewer workers than are needed for older manual sequence-generation processes, and greatly reduces sequence-generation times. The sequences are embodied in spacecraft activity sequence files (SASFs). AutoGen automates generation of SASFs by use of another previously reported program called APGEN. AutoGen encodes knowledge of different mission phases and of how the resultant commands must differ among the phases. AutoGen also provides means for customizing sequences through use of configuration files. The approach followed in developing AutoGen has involved encoding the behaviors of a system into a model and encoding algorithms for context-sensitive customizations of the modeled behaviors. This version of AutoGen addressed the MRO (Mars Reconnaissance Orbiter) primary science phase (PSP) mission phase. On previous Mars missions this phase has more commonly been referred to as mapping phase. This version addressed the unique aspects of sequencing orbital operations and specifically the mission specific adaptation of orbital operations for MRO. This version also includes capabilities for MRO s role in Mars relay support for UHF relay communications with the MER rovers and the Phoenix lander.

Gladden, Roy E.↗
NASA NTRS1968

Accumulator for shaft encoder

Digital accumulator relies almost entirely on integrated circuitry to process the data derived from the outputs of gyro shaft encoder. After the read command is given, the output register collects and stores the data that are on the set output terminals of the up-down counters.

Carroll, C. C.↗
NASA NTRS1986

A database management capability for Ada

The data requirements of mission critical defense systems have been increasing dramatically. Command and control, intelligence, logistics, and even weapons systems are being required to integrate, process, and share ever increasing volumes of information. To meet this need, systems are now being specified that incorporate data base management subsystems for handling storage and retrieval of information. It is expected that a large number of the next generation of mission critical systems will contain embedded data base management systems. Since the use of Ada has been mandated for most of these systems, it is important to address the issues of providing data base management capabilities that can be closely coupled with Ada. A comprehensive distributed data base management project has been investigated. The key deliverables of this project are three closely related prototype systems implemented in Ada. These three systems are discussed.

Chan, Arvola↗
NASA NTRS1994

OOD/OOP experience in the Science Operations Center part of the ground system for X ray Timing Explorer mission

The Science Operations Center (SOC) for the X-ray Timing Explorer (XTE) mission is an important component of the XTE ground system. Its mandate includes: (1) command and telemetry for the three XTE instruments, using CCSDS standards; (2) monitoring of the real-time science operations, reconfiguration of the experiment and the instruments, and real-time commanding to address the targets of opportunity (TOO) and alternate observations; and (3) analysis, processing, and archival of the XTE telemetry, and the timely delivery of the data products to the principal investigator (PI) teams and the guest observers (GO). The SOC has two major components: the science operations facility (SOF) that addresses the first two objectives stated above and the guest observer facility (GOF) that addresses the third. The SOF has subscribed to the object oriented design and implementation; while the GOF uses the traditional approach in order to take advantage of the existing software developed in support of previous missions. This paper details the SOF development using the object oriented design (OOD), and its implementation using the object oriented programming (OOP) in C++ under Unix environment on client-server architecture using Sun workstations. It also illustrates how the object oriented (OO) and the traditional approaches coexist in SOF and GOF, the lessons learned, and how the OOD facilitated the distributed software development collaboratively by four different teams. Details are presented for the SOF system, its major subsystems, its interfaces with the rest of the XTE ground data system, and its design and implementation approaches.

Choudhary, Abdur Rahim↗
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↗