SEARCH · Engineering Papers

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.

SourceResearch connectionFrom yearThrough year

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

At least 901 records · Page 50

All sources NASA NTRS DOE OSTI

NASA NTRS2004

Summary of the key features of seven biomathematical models of human fatigue and performance

BACKGROUND: Biomathematical models that quantify the effects of circadian and sleep/wake processes on the regulation of alertness and performance have been developed in an effort to predict the magnitude and timing of fatigue-related responses in a variety of contexts (e.g., transmeridian travel, sustained operations, shift work). This paper summarizes key features of seven biomathematical models reviewed as part of the Fatigue and Performance Modeling Workshop held in Seattle, WA, on June 13-14, 2002. The Workshop was jointly sponsored by the National Aeronautics and Space Administration, U.S. Department of Defense, U.S. Army Medical Research and Materiel Command, Office of Naval Research, Air Force Office of Scientific Research, and U.S. Department of Transportation. METHODS: An invitation was sent to developers of seven biomathematical models that were commonly cited in scientific literature and/or supported by government funding. On acceptance of the invitation to attend the Workshop, developers were asked to complete a survey of the goals, capabilities, inputs, and outputs of their biomathematical models of alertness and performance. Data from the completed surveys were summarized and juxtaposed to provide a framework for comparing features of the seven models. RESULTS: Survey responses revealed that models varied greatly relative to their reported goals and capabilities. While all modelers reported that circadian factors were key components of their capabilities, they differed markedly with regard to the roles of sleep and work times as input factors for prediction: four of the seven models had work time as their sole input variable(s), while the other three models relied on various aspects of sleep timing for model input. Models also differed relative to outputs: five sought to predict results from laboratory experiments, field, and operational data, while two models were developed without regard to predicting laboratory experimental results. All modelers provided published papers describing their models, with three of the models being proprietary. CONCLUSIONS: Although all models appear to have been fundamentally influenced by the two-process model of sleep regulation by Borbely, there is considerable diversity among them in the number and type of input and output variables, and their stated goals and capabilities.

Fatigue/physiopathology↗

NASA NTRS2004

Caltrans Keeps the Spitzer Pipelines Moving

The computer pipelines used to process digital infrared astronomical images from NASA's Spitzer Space Telescope require various input calibration-data files for characterizing the attributes and behaviors of the onboard focal-plane-arrays and their detector pixels, such as operability, dark-current offset, linearity, non- uniformity, muxbleed, droop, and point-response functions. The telescope has three very different science instruments, each with three or four spectral-band-pass channels, depending on the instrument. Moreover, each instrument has various operating modes (e-g., full array or sub-array in one case) and parameters (e.g., integration time). Calibration data that depend on these considerations are needed by pipelines for generating both science products (production pipelines) and higher-level calibration products (calibration pipelines). The calibration files are created in various formats either 'off-line' or by the aforementioned calibration pipelines, depending on the above configuration details. Also, the calibration files are generally applicable to a certain time period and therefore must be selected accordingly for a given raw input image to be correctly processed. All of this complexity in selecting and retrieving calibration files for pipeline processing is handled by a procedural software-program called 'caltrans' . This software, which is implemented in C and interacts with an Informix database, was developed at the Spitzer Science Center (SSC) and is now deployed in SSC daily operations. The software is rule-based, very flexible, and, for efficiency, capable of retrieving multiple calibration files with a single software-execution command.

Spitzer↗

NASA NTRS2003

Wavelet-Based Real-Time Diagnosis of Complex Systems

A new method of robust, autonomous real-time diagnosis of a time-varying complex system (e.g., a spacecraft, an advanced aircraft, or a process-control system) is presented here. It is based upon the characterization and comparison of (1) the execution of software, as reported by discrete data, and (2) data from sensors that monitor the physical state of the system, such as performance sensors or similar quantitative time-varying measurements. By taking account of the relationship between execution of, and the responses to, software commands, this method satisfies a key requirement for robust autonomous diagnosis, namely, ensuring that control is maintained and followed. Such monitoring of control software requires that estimates of the state of the system, as represented within the control software itself, are representative of the physical behavior of the system. In this method, data from sensors and discrete command data are analyzed simultaneously and compared to determine their correlation. If the sensed physical state of the system differs from the software estimate (see figure) or if the system fails to perform a transition as commanded by software, or such a transition occurs without the associated command, the system has experienced a control fault. This method provides a means of detecting such divergent behavior and automatically generating an appropriate warning.

Gulati, Sandeep↗

NASA NTRS2017

XTCE (XML Telemetric and Command Exchange) Standard Making It Work at NASA. Can It Work For You?

The XML Telemetric and Command Exchange (XTCE) standard is intended as a way to describe telemetry and command databases to be exchanged across centers and space agencies. XTCE usage has the potential to lead to consolidation of the Mission Operations Center (MOC) Monitor and Control displays for mission cross-support, reducing equipment and configuration costs, as well as a decrease in the turnaround time for telemetry and command modifications during all the mission phases. The adoption of XTCE will reduce software maintenance costs by reducing the variation between our existing mission dictionaries. The main objective of this poster is to show how powerful XTCE is in terms of interoperability across centers and missions. We will provide results for a use case where two centers can use their local tools to process and display the same mission telemetry in their MOC independently of one another. In our use case we have first quantified the ability for XTCE to capture the telemetry definitions of the mission by use of our suite of support tools (Conversion, Validation, and Compliance measurement). The next step was to show processing and monitoring of the same telemetry in two mission centers. Once the database was converted to XTCE using our tool, the XTCE file became our primary database and was shared among the various tool chains through their XTCE importers and ultimately configured to ingest the telemetry stream and display or capture the telemetered information in similar ways.Summary results include the ability to take a real mission database and real mission telemetry and display them on various tools from two centers, as well as using commercially free COTS.

CCSDS↗

NASA NTRS1974

Pioneer Odyssey: Encounter with a Giant

Ancient peoples, perhaps thousands of years ago, undoubtedly conceived the idea of "reaching out" to Jupiter, the largest and most brilliant of the "wandering stars." But for mankind to stretch across the half billion miles to the giant planet of the Solar System many advances in technical and organizational fields of human endeavor had to be made. Outreach to Jupiter did not become a serious possibility until the Pioneer F and G Project was formed by NASA early in 1968. And then man began to design an extension of his senses that would probe the environs of the giant of the Solar System, a truly pioneer odyssey into the virtually unknown regions beyond the orbit of Mars. In the ensuing year. a dedicated and cooperative effort of several thousand people in Government, university, and private industrial organizations converted the idea into a reality. Less than twelve generations after Galileo first saw the banded disc of Jupiter and the flickering dots of its large satellites in the newly invented telescope, mankind sent a machine to make observations within that Jovian system. The two Pioneer spacecraft for the mission to Jupiter each weighed only about 570 pounds, yet carried eleven highly sophisticated instruments capable of operating unattended for many year in space. The spacecraft consumes less electrical power than a standard 100 watt lamp yet is able to accept instructions from Earth to control numerous operating modes of its scientific payload, process observations from these scientific instruments and format the observations into information usable on Earth. Even more remarkable. the spacecraft transmits a radio signal of only 8 watts power - equal to a nightlight - yet the information carried by the radio signal is received back on Earth from a distance of several billion miles. The Pioneer mission could not have been a success without the special engineering, scientific and management organization created for its accomplishment. This organization was rather unique in that it first had to meet a launch date target relatively quickly and then had to function for an extremely long mission operational time, far longer than any previous mission to planets. The first task was thus to organize so that the mission could be planned and the spacecraft designed and fabricated to be ready for launch within a few weeks of a 30-month target for completion. The program also produced an organization that planned mission operations to such detail that more than 16,000 commands were transmitted flawlessly to the distant spacecraft during Jupiter encounter. And each command reached the spacecraft within one second of the planned time despite the more than 90 minutes required for the radio message to travel from Earth to the spacecraft and for the spacecraft to return a confirmation to controllers back on Earth. The organization for Pioneer also determined the required flight path from Earth to Jupiter with such precision, and controlled the launch vehicle with such accuracy, that 21 months after launch the spacecraft was able to fly behind Jupiter's satellite lo, thereby providing the first measurement that indicated the possibility of a tenuous atmosphere about this large satellite. Finally, the Pioneer organization processed and analyzed each year sufficient information from the spacecraft to fill a book having about 3 million pages and reduced this avalanche of data from space into summaries of manageable size. And all this organization depended on people, consisted of people: the people who really made this whole mission possible. Pioneer has always depended on the dedication of many individuals from many organizations throughout the world to achieve its scientific objectives, and, as evidenced by the success of the Pioneer series, this dependence is completely justified. Relatively few individuals have an opportunity during their lives to participate in such a challenging, historic, pioneering effort; and still fewer are able to enjoy the rewards of such an activity. We who have worked on Pioneer 10 and its sister spacecraft, Pioneer 11, consider ourselves fortunate to be in both classes. For the opportunity we thank the people of the United States of America, who have supported our country's space effort and its spreading of human awareness of a vast and intriguing universe in which our own unique planet Earth is only one of myriads of worlds. This volume describing the mission to Jupiter and its results is one of the many rewards for our effort which we share with you, the reader.

Fimmel, Richard O.↗

NASA NTRS1971

Simulation of Mariner Mars 1971 spacecraft

Preparation for the Mariner Mars 1971 mission is reported, including an extensive training program for operations personnel during which the primary source of spacecraft data was a computer program simulating the spacecraft. The objectives of a simulation model for training purposes differed from objectives appropriate to a design or analysis model. Model subsystems were designed to provide realistic telemetry data reflecting changes due both to commands and environmental parameters affecting the spacecraft at various times during the mission. The spacecraft is modeled along two separate functional lines. Boolean operations are concentrated in the spacecraft logic model, which determines the spacecraft state or mode, while mathematical operations or algorithms are executed in computational subsystem models. Although logic parameters are interrogated as a part of each computational pass, actual logic model processing occurs only when a change-of-state input is generated by the operations organization. The program design, some of the special characteristics of each of the modeled subsystems, and how the model was used in support of mission operations training are presented.

Ausman, N. E., Jr.↗

NASA NTRS1971

A spacecraft computer repairable via command.

The MULTIPAC is a central data system developed for deep-space probes with the distinctive feature that it may be repaired during flight via command and telemetry links by reprogramming around the failed unit. The computer organization uses pools of identical modules which the program organizes into one or more computers called processors. The interaction of these modules is dynamically controlled by the program rather than hardware. In the event of a failure, new programs are entered which reorganize the central data system with a somewhat reduced total processing capability aboard the spacecraft. Emphasis is placed on the evolution of the system architecture and the final overall system design rather than the specific logic design.

Fimmel, R. O.↗

NASA NTRS1987

Planning the Voyager spacecraft's mission to Uranus

The application of the systems engineering process to the planning of the Voyager spacecraft mission is described. The Mission Planning Office prepared guidelines that controlled the use of the project and multimission resources and spacecraft consumables in order to obtain valuable scientific data at an acceptable risk level. Examples of mission planning which are concerned with the design of the Deep Space Network antenna, the uplink window for transmitting computer command subsystem loads, and the contingency and risk assessment functions are presented.

Plagemann, Stephen H.↗

NASA NTRS1987

Range and mission scheduling automation using combined AI and operations research techniques

Ground-based systems for Satellite Command, Control, and Communications (C3) operations require a method for planning, scheduling and assigning the range resources such as: antenna systems scattered around the world, communications systems, and personnel. The method must accommodate user priorities, last minute changes, maintenance requirements, and exceptions from nominal requirements. Described are computer programs which solve 24 hour scheduling problems, using heuristic algorithms and a real time interactive scheduling process.

Arbabi, Mansur↗

NASA NTRS1994

A new systems engineering approach to streamlined science and mission operations for the Far Ultraviolet Spectroscopic Explorer (FUSE)

The Mission Operations and Data Systems Directorate (MO&DSD, Code 500), the Space Sciences Directorate (Code 600), and the Flight Projects Directorate (Code 400) have developed a new approach to combine the science and mission operations for the FUSE mission. FUSE, the last of the Delta-class Explorer missions, will obtain high resolution far ultraviolet spectra (910 - 1220 A) of stellar and extragalactic sources to study the evolution of galaxies and conditions in the early universe. FUSE will be launched in 2000 into a 24-hour highly eccentric orbit. Science operations will be conducted in real time for 16-18 hours per day, in a manner similar to the operations performed today for the International Ultraviolet Explorer. In a radical departure from previous missions, the operations concept combines spacecraft and science operations and data processing functions in a single facility to be housed in the Laboratory for Astronomy and Solar Physics (Code 680). A small missions operations team will provide the spacecraft control, telescope operations and data handling functions in a facility designated as the Science and Mission Operations Center (SMOC). This approach will utilize the Transportable Payload Operations Control Center (TPOCC) architecture for both spacecraft and instrument commanding. Other concepts of integrated operations being developed by the Code 500 Renaissance Project will also be employed for the FUSE SMOC. The primary objective of this approach is to reduce development and mission operations costs. The operations concept, integration of mission and science operations, and extensive use of existing hardware and software tools will decrease both development and operations costs extensively. This paper describes the FUSE operations concept, discusses the systems engineering approach used for its development, and the software, hardware and management tools that will make its implementation feasible.

Butler, Madeline J.↗

NASA NTRS1995

Control method for prosthetic devices

A control system and method for prosthetic devices is provided. The control system comprises a transducer for receiving movement from a body part for generating a sensing signal associated with that movement. The sensing signal is processed by a linearizer for linearizing the sensing signal to be a linear function of the magnitude of the distance moved by the body part. The linearized sensing signal is normalized to be a function of the entire range of body part movement from the no-shrug position of the moveable body part. The normalized signal is divided into a plurality of discrete command signals. The discrete command signals are used by typical converter devices which are in operational association with the prosthetic device. The converter device uses the discrete command signals for driving the moveable portions of the prosthetic device and its sub-prosthesis. The method for controlling a prosthetic device associated with the present invention comprises the steps of receiving the movement from the body part, generating a sensing signal in association with the movement of the body part, linearizing the sensing signal to be a linear function of the magnitude of the distance moved by the body part, normalizing the linear signal to be a function of the entire range of the body part movement, dividing the normalized signal into a plurality of discrete command signals, and implementing the plurality of discrete command signals for driving the respective moveable prosthesis device and its sub-prosthesis.

Bozeman, Richard J., Jr.↗

NASA NTRS1998

A Photo Album of Earth Scheduling Landsat 7 Mission Daily Activities

Landsat7 is a member of a new generation of Earth observation satellites. Landsat7 will carry on the mission of the aging Landsat 5 spacecraft by acquiring high resolution, multi-spectral images of the Earth surface for strategic, environmental, commercial, agricultural and civil analysis and research. One of the primary mission goals of Landsat7 is to accumulate and seasonally refresh an archive of global images with full coverage of Earth's landmass, less the central portion of Antarctica. This archive will enable further research into seasonal, annual and long-range trending analysis in such diverse research areas as crop yields, deforestation, population growth, and pollution control, to name just a few. A secondary goal of Landsat7 is to fulfill imaging requests from our international partners in the mission. Landsat7 will transmit raw image data from the spacecraft to 25 ground stations in 20 subscribing countries. Whereas earlier Landsat missions were scheduled manually (as are the majority of current low-orbit satellite missions), the task of manually planning and scheduling Landsat7 mission activities would be overwhelmingly complex when considering the large volume of image requests, the limited resources available, spacecraft instrument limitations, and the limited ground image processing capacity, not to mention avoidance of foul weather systems. The Landsat7 Mission Operation Center (MOC) includes an image scheduler subsystem that is designed to automate the majority of mission planning and scheduling, including selection of the images to be acquired, managing the recording and playback of the images by the spacecraft, scheduling ground station contacts for downlink of images, and generating the spacecraft commands for controlling the imager, recorder, transmitters and antennas. The image scheduler subsystem autonomously generates 90% of the spacecraft commanding with minimal manual intervention. The image scheduler produces a conflict-free schedule for acquiring images of the "best" 250 scenes daily for refreshing the global archive. It then equitably distributes the remaining resources for acquiring up to 430 scenes to satisfy requests by international subscribers. The image scheduler selects candidate scenes based on priority and age of the requests, and predicted cloud cover and sun angle at each scene. It also selects these scenes to avoid instrument constraint violations and maximizes efficiency of resource usage by encouraging acquisition of scenes in clusters. Of particular interest to the mission planners, it produces the resulting schedule in a reasonable time, typically within 15 minutes.

Potter, William↗

NASA NTRSDate not supplied

cFS Test Framework (CTF)

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

Aly I Shehata↗

NASA NTRSDate not supplied

CFS Test Framework

cfs↗

NASA NTRS2013

Cloud Absorption Radiometer Autonomous Navigation System - CANS

CAR (cloud absorption radiometer) acquires spatial reference data from host aircraft navigation systems. This poses various problems during CAR data reduction, including navigation data format, accuracy of position data, accuracy of airframe inertial data, and navigation data rate. Incorporating its own navigation system, which included GPS (Global Positioning System), roll axis inertia and rates, and three axis acceleration, CANS expedites data reduction and increases the accuracy of the CAR end data product. CANS provides a self-contained navigation system for the CAR, using inertial reference and GPS positional information. The intent of the software application was to correct the sensor with respect to aircraft roll in real time based upon inputs from a precision navigation sensor. In addition, the navigation information (including GPS position), attitude data, and sensor position details are all streamed to a remote system for recording and later analysis. CANS comprises a commercially available inertial navigation system with integral GPS capability (Attitude Heading Reference System AHRS) integrated into the CAR support structure and data system. The unit is attached to the bottom of the tripod support structure. The related GPS antenna is located on the P-3 radome immediately above the CAR. The AHRS unit provides a RS-232 data stream containing global position and inertial attitude and velocity data to the CAR, which is recorded concurrently with the CAR data. This independence from aircraft navigation input provides for position and inertial state data that accounts for very small changes in aircraft attitude and position, sensed at the CAR location as opposed to aircraft state sensors typically installed close to the aircraft center of gravity. More accurate positional data enables quicker CAR data reduction with better resolution. The CANS software operates in two modes: initialization/calibration and operational. In the initialization/calibration mode, the software aligns the precision navigation sensors and initializes the communications interfaces with the sensor and the remote computing system. It also monitors the navigation data state for quality and ensures that the system maintains the required fidelity for attitude and positional information. In the operational mode, the software runs at 12.5 Hz and gathers the required navigation/attitude data, computes the required sensor correction values, and then commands the sensor to the required roll correction. In this manner, the sensor will stay very near to vertical at all times, greatly improving the resulting collected data and imagery. CANS greatly improves quality of resulting imagery and data collected. In addition, the software component of the system outputs a concisely formatted, high-speed data stream that can be used for further science data processing. This precision, time-stamped data also can benefit other instruments on the same aircraft platform by providing extra information from the mission flight.

Kahle, Duncan↗

NASA NTRS1988

The Environment for Application Software Integration and Execution (EASIE), version 1.0. Volume 3: Program execution guide

The Environment for Application Software Integration and Execution, EASIE, provides a methodology and a set of software utility programs to ease the task of coordinating engineering design and analysis codes. EASIE was designed to meet the needs of conceptual design engineers that face the task of integrating the results of many stand-alone engineering analysis programs. EASIE provides access to these programs via a quick, uniform, user-friendly interface. In addition, EASIE provides utilities which aid in the execution of the following tasks: selection of application programs, modification and review of program data, automatic definition and coordination of data files during program execution and a logging of steps executed throughout a design study. Volume 3, the Program Execution Guide, describes the executive capabilities provided by EASIE and defines the command language and menus available under Version 1.0. EASIE provides users with two basic modes of operation. One is the Application-Derived Executive (ADE) which provides users with sufficient guidance to quickly review data, select menu action items, and execute application programs. The second is the Complete Control Executive (CCE), which provides a full executive interface allowing users in-depth control of the design process.

Schwing, James L.↗

NASA NTRS1989

Orbital maneuvering vehicle teleoperation and video data compression

The Orbital Maneuvering Vehicle (OMV) and concepts of teleoperation and video data compression as applied to OMV design and operation are described. The OMV provides spacecraft delivery, retrieval, reboost, deboost and viewing services, with ground-control or Space Station operation, through autonomous navigation and pilot controlled maneuvers. Communications systems are comprised of S-band RF command, telemetry, and compressed video data links through the TDRSS and GSTDN networks. The control console video monitors display a monochrome image at an update rate of five frames per second. Depending upon the mode of operation selected by the pilot, the video resolution is either 255 x 244 pixels, or 510 x 244 pixels. Since practically all video image redundancy is removed by the compression process, the video reconstruction is particularly sensitive to data transmission bit errors. Concatenated Reed-Solomon and convolution coding are used with helical data interleaving for error detection and correction, and an error-containment process minimizes the propagation of error effects throughout the video image. Video sub-frame replacement is used, in the case of a non-correctable error or error burst, to minimize the visual impact to the pilot.

Jones, Steve↗

NASA NTRS2006

MSL EDL Entry Guidance using the Entry Terminal Point Controller

The Mars Science Laboratory will be the first Mars mission to attempt a guided entry with the objective of safely delivering the entry vehicle to a survivable parachute deploy state within 10 km of the pre-designated landing site. The Entry Terminal Point Controller guidance algorithm is derived from the final phase Apollo Command Module guidance and, like Apollo, modulates the bank angle to control range based on deviations in range, altitude rate, and drag acceleration from a reference trajectory. For application to Mars landers which must make use of the tenuous Martian atmosphere, it is critical to balance the lift of the vehicle to minimize the range while still ensuring a safe deploy altitude. An overview of the process to generate optimized guidance settings is presented, discussing improvements made over the last four years. Performance tradeoffs between ellipse size and deploy altitude will be presented, along with imposed constraints of entry acceleration and heating. Performance sensitivities to the bank reversal deadbands, heading alignment, attitude initialization error, and atmospheric delivery errors are presented. Guidance settings for contingency operations, such as those appropriate for severe dust storm scenarios, are evaluated.

Source record↗