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 721 records · Page 40

Emergency Response Fire-Imaging UAS Missions over the Southern California Wildfire Disaster

Objectives include: Demonstrate capabilities of UAS to overfly and collect sensor data on widespread fires throughout Western US. Demonstrate long-endurance mission capabilities (20-hours+). Image multiple fires (greater than 4 fires per mission), to showcase extendable mission configuration and ability to either linger over key fires or station over disparate regional fires. Demonstrate new UAV-compatible, autonomous sensor for improved thermal characterization of fires. Provide automated, on-board, terrain and geo-rectified sensor imagery over OTH satcom links to national fire personnel and Incident commanders. Deliver real-time imagery (within 10-minutes of acquisition). Demonstrate capabilities of OTS technologies (GoogleEarth) to serve and display mission-critical sensor data, coincident with other pertinent data elements to facilitate information processing (WX data, ground asset data, other satellite data, R/T video, flight track info, etc).

DelFrate, John H.↗

DSN Resource Scheduling

TIGRAS is client-side software, which provides tracking-station equipment planning, allocation, and scheduling services to the DSMS (Deep Space Mission System). TIGRAS provides functions for schedulers to coordinate the DSN (Deep Space Network) antenna usage time and to resolve the resource usage conflicts among tracking passes, antenna calibrations, maintenance, and system testing activities. TIGRAS provides a fully integrated multi-pane graphical user interface for all scheduling operations. This is a great improvement over the legacy VAX VMS command line user interface. TIGRAS has the capability to handle all DSN resource scheduling aspects from long-range to real time. TIGRAS assists NASA mission operations for DSN tracking of station equipment resource request processes from long-range load forecasts (ten years or longer), to midrange, short-range, and real-time (less than one week) emergency tracking plan changes. TIGRAS can be operated by NASA mission operations worldwide to make schedule requests for the DSN station equipment.

Wang, Yeou-Fang↗

The Livingstone Model of a Main Propulsion System

Livingstone is a discrete, propositional logic-based inference engine that has been used for diagnosis of physical systems. We present a component-based model of a Main Propulsion System (MPS) and say how it is used with Livingstone (L2) in order to implement a diagnostic system for integrated vehicle health management (IVHM) for the Propulsion IVHM Technology Experiment (PITEX). We start by discussing the process of conceptualizing such a model. We describe graphical tools that facilitated the generation of the model. The model is composed of components (which map onto physical components), connections between components and constraints. A component is specified by variables, with a set of discrete, qualitative values for each variable in its local nominal and failure modes. For each mode, the model specifies the component's behavior and transitions. We describe the MPS components' nominal and fault modes and associated Livingstone variables and data structures. Given this model, and observed external commands and observations from the system, Livingstone tracks the state of the MPS over discrete time-steps by choosing trajectories that are consistent with observations. We briefly discuss how the compiled model fits into the overall PITEX architecture. Finally we summarize our modeling experience, discuss advantages and disadvantages of our approach, and suggest enhancements to the modeling process.

Bajwa, Anupa↗

Post-Flight EDL Entry Guidance Performance of the 2011 Mars Science Laboratory Mission

The 2011 Mars Science Laboratory was the first successful Mars mission to attempt a guided entry which safely delivered the rover to a final position approximately 2 km from its target within a touchdown ellipse of 19.1 km x 6.9 km. 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 the range flown. 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 error 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 nine years. Key dispersions driving deploy ellipse and altitude performance are identified. Performance sensitivities including attitude initialization error and the velocity of transition from range control to heading alignment are presented. Just prior to the entry and landing of MSL in August 2012, the EDL team examined minute tuning of the reference trajectory for the selected landing site, analyzed whether adjustment of bank reversal deadbands were necessary, the heading alignment velocity trigger was in union with other parameters to balance the EDL risks, and the vertical L/D command limits. This paper details a preliminary postflight assessment of the telemetry and trajectory reconstruction that is being performed, and updates the information presented in the former paper Entry Guidance for the 2011 Mars Science Laboratory Mission (AIAA Atmospheric Flight Mechanics Conference; 8-11 Aug. 2011; Portland, OR; United States)

Mendeck, Gavin F.↗

Wings: A New Paradigm in Human-Centered Design

Many aircraft accidents/incidents investigations cite crew error as a causal factor (Boeing Commercial Airplane Group 1996). Human factors experts suggest that crew error has many underlying causes and should be the start of an accident investigation and not the end. One of those causes, the flight deck design, is correctable. If a flight deck design does not accommodate the human's unique abilities and deficits, crew error may simply be the manifestation of this mismatch. Pilots repeatedly report that they are "behind the aircraft" , i.e., they do not know what the automated aircraft is doing or how the aircraft is doing it until after the fact. Billings (1991) promotes the concept of "human-centered automation"; calling on designers to allocate appropriate control and information to the human. However, there is much ambiguity regarding what it mean's to be human-centered. What often are labeled as "human-centered designs" are actually designs where a human factors expert has been involved in the design process or designs where tests have shown that humans can operate them. While such designs may be excellent, they do not represent designs that are systematically produced according to some set of prescribed methods and procedures. This paper describes a design concept, called Wings, that offers a clearer definition for human-centered design. This new design concept is radically different from current design processes in that the design begins with the human and uses the human body as a metaphor for designing the aircraft. This is not because the human is the most important part of the aircraft (certainly the aircraft would be useless without lift and thrust), but because he is the least understood, the least programmable, and one of the more critical elements. The Wings design concept has three properties: a reversal in the design process, from aerodynamics-, structures-, and propulsion-centered to truly human-centered; a design metaphor that guides function allocation and control and display design; and a deliberate distinction between two fundamental functions of design, to complement and to interpret human performance. The complementary function extends the human's capabilities beyond his or her current limitations - this includes sensing, computation, memory, physical force, and human decision making styles and skills. The interpretive (or hermeneutic, Hollnagel 1991) function translates information, functionality, and commands between the human and the aircraft. The Wings design concept allows the human to remain aware of the aircraft through natural interpretation. It also affords great improvements in system performance by maximizing the human's natural abilities and complementing the human's skills in a natural way. This paper will discuss the Wings design concept by describing the reversal in the traditional design process, the function allocation strategy of Wings, and the functions of complementing and interpreting the human.

Schutte, Paul C.↗

VIPER Lunar Rover Agile Mission Systems

Agile development methods, which have gone from outlier to mainstream in software development, are poised to expand into all aspects of space mission development. Modern software development operates on a principle of continuous deployment, where progress is verified not with conventional metrics, but with a continuous build, available to key stakeholders, enabling direct examination of the state of the code base, and assessment of progress through demonstration of capability. Delivery times are measured in weeks, not months. Stakeholders are part of the process on an ongoing basis. The cost of change is comparatively low and requirements, which often are not precisely defined at the start of a project, may be iteratively refined in a series of agile development cycles. Agile methods are compatible with traditional system engineering methods and may be tailored to the space operations environment. The low cost of change and iterative development cycles of agile enable requirements to be defined as outcomes and constraints, with design details to be refined during the development cycle. We are now at a point where agile methods may be extended beyond software, to Mission Systems, including the Mission Operations System and the Ground Data System. For NASA’s VIPER Lunar Rover Mission, scheduled to land at a lunar pole in late 2023, we are developing the Mission System using agile methods. As in agile software, where the measure of progress is working code, in agile mission system development, the measure of capability is what we can demonstrate. Demonstrations over presentations. We demonstrate mission system capability using simulations. The concept of operations, from commanding, to driving the rover, to how we downlink images for evaluation for a near-real time command cycle, will be tested and proven in simulation, years before we begin the traditional simulation cycle for training. “Say it then simulate it.” We develop and refine our designs using simulations, with an emphasis on new components of the system that are not well known early. For example, the required duration of a mission planning cycle for a lunar surface asset such as VIPER, that operates twenty-four hours a day, seven days a week, with continuous communications and a unique set of constraints based on the physics of the lunar poles and the line of site to Earth, is a unique problem in mission planning that is unlikely to be solved in a series of meetings. A small number of requirements specifying the outcomes may serve as the jumping off point to an agile development cycle, with demonstration in simulations. We have already demonstrated this process with simulations of rover driver decision time. VIPER is driven using near-real time command and control to waypoints. The driver decision time between waypoints is a fundamental enabling unit of productivity to accomplish the mission timeline. We have validated driver decision time in simulations of rover driving at the lunar South Pole, using the prototype mission tools for driving, command and control. The capability to develop and refine designs using simulations as part of agile Mission System development cycle changes the nature of team interactions, creating a focus on doing, rather than analyzing and documenting. Waterfall development cycles were, in part, a product of the significant cost of change in the early days of spaceflight. When the cost of change is high, it is vital to get your requirements right at the outset, because the system will be built to those specifications, and, when change is expensive, you better get it right early. However, modern technology has greatly lowered the cost of change, enabling iterative, rapid development cycles, in which key operations concepts may be tested and refined during development. Extending agile development to the Mission System for VIPER is a significant step in moving agile development methods for space operations beyond software, to the Mission System.

Agile↗

Using XML and Java for Astronomical Instrumentation Control

Traditionally, instrument command and control systems have been highly specialized, consisting mostly of custom code that is difficult to develop, maintain, and extend. Such solutions are initially very costly and are inflexible to subsequent engineering change requests, increasing software maintenance costs. Instrument description is too tightly coupled with details of implementation. NASA Goddard Space Flight Center is developing a general and highly extensible framework that applies to any kind of instrument that can be controlled by a computer. The software architecture combines the platform independent processing capabilities of Java with the power of the Extensible Markup Language (XML), a human readable and machine understandable way to describe structured data. A key aspect of the object-oriented architecture is software that is driven by an instrument description, written using the Instrument Markup Language (IML). ]ML is used to describe graphical user interfaces to control and monitor the instrument, command sets and command formats, data streams, and communication mechanisms. Although the current effort is targeted for the High-resolution Airborne Wideband Camera, a first-light instrument of the Stratospheric Observatory for Infrared Astronomy, the framework is designed to be generic and extensible so that it can be applied to any instrument.

Ames, Troy↗

The ISS EXPRESS Rack: An Innovative Approach of Rapid Integration

The EXpedite the PRocessing of Experiments to Space Station or EXPRESS Rack System, was developed to provide Space Station accommodations for small, subrack payloads. The EXPRESS Rack accepts Space Shuttle middeck locker type payloads and International Subrack Interface Standard (ISIS) Drawer payloads, allowing previously flown payloads an opportunity to transition to the International Space Station. The EXPRESS Rack provides power, data, command and control, video, water cooling, air cooling, vacuum exhaust, and Nitrogen supply to payloads. The EXPRESS Rack system also includes transportation racks to transport payloads to and from the Space Station, Suitcase Simulators to allow a payload developer to verify power and data interfaces at the development site, Functional Checkout Units to allow Payload checkout at KSC prior to launch, and trainer racks for the astronauts to learn how to operate the EXPRESS Racks prior to flight. Standard hardware and software interfaces provided by the EXPRESS Rack simplify the analytical and physical integration processes, and facilitates simpler ISS payload development. The EXPRESS Rack has also formed the basis for the U.S. Life Sciences payload racks and the Window Observational Research Facility on Space Station.

Sledd, Annette M.↗

EXPRESS Rack Overview

The EXpedite the PRocessing of Experiments to Space Station or EXPRESS Rack System, was developed to provide Space Station accommodations for small, subrack payloads. The EXPRESS Rack accepts Space Shuttle middeck locker type payloads and International Subrack Interface Standard (ISIS) Drawer payloads, allowing previously flown payloads an opportunity to transition to the International Space Station. The EXPRESS Rack provides power, data, command and control, video, water cooling, air cooling, vacuum exhaust, and Nitrogen supply to payloads. The EXPRESS Rack system also includes transportation racks to transport payloads to and from the Space Station, Suitcase Simulators to allow a payload developer to verify power and data interfaces at the development site, Functional Checkout Units to allow Payload checkout at KSC prior to launch, and trainer racks for the astronauts to learn how to operate the EXPRESS Racks prior to flight. Standard hardware and software interfaces provided by the EXPRESS Rack simplify the analytical and physical integration processes, and facilitates simpler ISS payload development. The EXPRESS Rack has also formed the basis for the U.S. Life Sciences payload racks on Space Station.

Sledd, Annette M.↗

DSN automation

An overall hierarchical automation philosophy along with the results of the radio frequencies automation effort undertaken 2 years ago are summarized. A brief description of each subassembly controller's salient features, the software development process, and the common software used by these controllers will be presented. Comments will be made with respect to the relative advantages of high-level language and assembly language, the operational effectiveness of operator Macro commands, and the program development, and a list of suggested future effort will be given.

Crow, R. B.↗

The USAF Systems Command and R and D productivity

The United States Air Force Systems Command (AFSC) is charged with the development and acquisition of aerospace technology systems. Much of that activity is concerned with space systems development, acquisition, and operations. Heavy emphasis is being placed on productivity in organizational and process functions which will keep aerospace systems on the leading edge of technology, with plans extending capability into the future. The productivity emphasis ranges from people-oriented activities to resource and technological functions which support national aerospace objectives. The AFSC space-related missions is discussed as a special area of productivity efforts.

Luchainger, V.↗

RHETT/EPDM Performance Characterization

The 0.6 kW Electric Propulsion Demonstration Module (EPDM) flight thruster system was tested in a large vacuum facility for performance measurements and functional checkout. The thruster was operated at a xenon flow rate of 3.01 mg/s, which was supplied through a self-contained propellant system. All power was provided through a flight-packaged power processing unit, which was mounted in vacuum on a cold plate. The thruster was cycled through 34 individual startup and shutdown sequences. Operating periods ranged from 3 to 3600 seconds. The system responded promptly to each command sequence and there were no involuntary shutdowns. Direct thrust measurements indicated that steady state thrust was temperature sensitive, and varied from a high of 41.7 mN at 16 C, to a low of 34.8 mN at 110 C. Short duration thruster firings showed rapid response and good repeatability.

Haag, T.↗

STS-96: Expedition Crew #2 and 4 Work in Node #1 at the SSPF

Live footage of the crewmembers of STS-96, Commander Kent V. Rominger, Pilot Rick D. Husband, Mission Specialists Ellen Ochoa, Tamara E. Jernigan, Daniel T. Barry, Julie Payette, and Valery Ivanovich Tokarev, shows them in the node of the vehicle at the Space Station Processing Facility (SSPF). Scenes include the engineer explaining and the crew asking questions as to what certain labels mean. Footage also includes the crew observing the nose of the vehicle.

Source record↗

Using XML and Java Technologies for Astronomical Instrument Control

Traditionally, instrument command and control systems have been highly specialized, consisting mostly of custom code that is difficult to develop, maintain, and extend. Such solutions are initially very costly and are inflexible to subsequent engineering change requests, increasing software maintenance costs. Instrument description is too tightly coupled with details of implementation. NASA Goddard Space Flight Center, under the Instrument Remote Control (IRC) project, is developing a general and highly extensible framework that applies to any kind of instrument that can be controlled by a computer. The software architecture combines the platform independent processing capabilities of Java with the power of the Extensible Markup Language (XML), a human readable and machine understandable way to describe structured data. A key aspect of the object-oriented architecture is that the software is driven by an instrument description, written using the Instrument Markup Language (IML), a dialect of XML. IML is used to describe the command sets and command formats of the instrument, communication mechanisms, format of the data coming from the instrument, and characteristics of the graphical user interface to control and monitor the instrument. The IRC framework allows the users to define a data analysis pipeline which converts data coming out of the instrument. The data can be used in visualizations in order for the user to assess the data in real-time, if necessary. The data analysis pipeline algorithms can be supplied by the user in a variety of forms or programming languages. Although the current integration effort is targeted for the High-resolution Airborne Wideband Camera (HAWC) and the Submillimeter and Far Infrared Experiment (SAFIRE), first-light instruments of the Stratospheric Observatory for Infrared Astronomy (SOFIA), the framework is designed to be generic and extensible so that it can be applied to any instrument. Plans are underway to test the framework with other types of instruments, such as remote sensing earth science instruments.

Ames, Troy↗

Methodology for Designing Fault-Protection Software

A document describes a methodology for designing fault-protection (FP) software for autonomous spacecraft. The methodology embodies and extends established engineering practices in the technical discipline of Fault Detection, Diagnosis, Mitigation, and Recovery; and has been successfully implemented in the Deep Impact Spacecraft, a NASA Discovery mission. Based on established concepts of Fault Monitors and Responses, this FP methodology extends the notion of Opinion, Symptom, Alarm (aka Fault), and Response with numerous new notions, sub-notions, software constructs, and logic and timing gates. For example, Monitor generates a RawOpinion, which graduates into Opinion, categorized into no-opinion, acceptable, or unacceptable opinion. RaiseSymptom, ForceSymptom, and ClearSymptom govern the establishment and then mapping to an Alarm (aka Fault). Local Response is distinguished from FP System Response. A 1-to-n and n-to- 1 mapping is established among Monitors, Symptoms, and Responses. Responses are categorized by device versus by function. Responses operate in tiers, where the early tiers attempt to resolve the Fault in a localized step-by-step fashion, relegating more system-level response to later tier(s). Recovery actions are gated by epoch recovery timing, enabling strategy, urgency, MaxRetry gate, hardware availability, hazardous versus ordinary fault, and many other priority gates. This methodology is systematic, logical, and uses multiple linked tables, parameter files, and recovery command sequences. The credibility of the FP design is proven via a fault-tree analysis "top-down" approach, and a functional fault-mode-effects-and-analysis via "bottoms-up" approach. Via this process, the mitigation and recovery strategy(s) per Fault Containment Region scope (width versus depth) the FP architecture.

Barltrop, Kevin↗

Glenn Heat Transfer Simulation and Solver Graphical User Interface: Development and Testing

In the Tui ine Branch of the Turbomachinery and Propulsion Systems Division, researching and developing efficient turbine aerothermodynamics technologies is the main objective. Creating effective turbines for jet engines is a process which, if based purely on physical experimental testing, would be extremely expensive. It is for this reason, and also for the reasons of speed and ease, that the Turbine Branch spends a large amount of effort working with simulations of turbines. Specifically, they focus their work on two main fields: Computational Field Dynamics (CFD), and Experimental data analysis. The experimental field involves comparing experimental results to simulated results, whereas the CFD field involves running these simulations. The simulations are applied to aerodynamics and heat transfer cases, for both steady and unsteady flow conditions. By and large this work is applied to the domain of flow and heat transfer in axial turbines. The main application used to run these heat flow simulations is GlennHT. This program, recently rewritten in FORTRAN 90, allows the user to input a job file which specifies all the necessary parameters needed to simulate flow through a user-defined grid. There are several other executables used as well, ranging in application from converting grid files to and from particular formats, to merging blocks in a connectivity file, to converting connectivity files to a GlennHT compatible format. All of these executables are run from the command line in a terminal; some of them have interactive prompts where the user must specify the files to be manipulated after the program starts, while others take all of their parameters from the command line. With this amount of variation comes a good deal of commands and formats to memorize, which can cause slower and less efficient work, as users may forget how to execute a certain program, or not remember the pathnames of the files they wish to use. Two years ago, steps were made to expedite this process with a graphical user interface (GUI) that combines the functionality of all the executables along with adding some new functionality, such as residuals graphing and boundary conditions creation. Upon my beginning here at Glenn, many parts of the GUI, which was developed in Java, were nonfunctional. There were also issues with cross-platforming, as systems in the branch were transitioning from Silicon Graphics (SGI) machines to Linux machines. My goals this summer are to finish the parts of the GUI that are not yet completed, fix parts that did not work correctly, expand the functionality to include other useful features, such as grid surface highlighting, and make the system compatible with both Linux and SGI. I will also be heavily testing the system and providing sufficient documentation on how to use the GUI, as no such documentation existed previously.

Kardamis, Joseph R.↗

Engineering and Scientific Applications: Using MatLab(Registered Trademark) for Data Processing and Visualization

MatLab(TradeMark)(MATrix LABoratory) is a numerical computation and simulation tool that is used by thousands Scientists and Engineers in many countries. MatLab does purely numerical calculations, which can be used as a glorified calculator or interpreter programming language; its real strength is in matrix manipulations. Computer algebra functionalities are achieved within the MatLab environment using "symbolic" toolbox. This feature is similar to computer algebra programs, provided by Maple or Mathematica to calculate with mathematical equations using symbolic operations. MatLab in its interpreter programming language form (command interface) is similar with well known programming languages such as C/C++, support data structures and cell arrays to define classes in object oriented programming. As such, MatLab is equipped with most of the essential constructs of a higher programming language. MatLab is packaged with an editor and debugging functionality useful to perform analysis of large MatLab programs and find errors. We believe there are many ways to approach real-world problems; prescribed methods to ensure foregoing solutions are incorporated in design and analysis of data processing and visualization can benefit engineers and scientist in gaining wider insight in actual implementation of their perspective experiments. This presentation will focus on data processing and visualizations aspects of engineering and scientific applications. Specifically, it will discuss methods and techniques to perform intermediate-level data processing covering engineering and scientific problems. MatLab programming techniques including reading various data files formats to produce customized publication-quality graphics, importing engineering and/or scientific data, organizing data in tabular format, exporting data to be used by other software programs such as Microsoft Excel, data presentation and visualization will be discussed.

Sen, Syamal K.↗

Development of a digital automatic control law for steep glideslope capture and flare

A longitudinal digital guidance and control law for steep glideslopes using MLS (Microwave Landing System) data is developed for CTOL aircraft using modern estimation and control techniques. The control law covers the final approach phases of glideslope capture, glideslope tracking, and flare to touchdown for automatic landings under adverse weather conditions. The control law uses a constant gain Kalman filter to process MLS and body-mounted accelerometer data to form estimates of flight path errors and wind velocities including wind shear. The flight path error estimates and wind estimates are used for feedback in generating control surface commands. Results of a digital simulation of the aircraft dynamics and the guidance and control law are presented for various wind conditions.

Halyo, N.↗