Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Flight Software”

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 1,549 records · Page 86

The Spacelab Experiment Interface Device (SEID)

The Spacelab experiment interface device (SEID) is described which simulates the electrical, and logical connections of the Spacelab remote acquisition unit (RAU), the interface functions of the Spacelab experiment computer software, and the electrical aspects of the high rate multiplexer. Simulated RAU interfaces include PCM serial channels (up to four), user time clock (UTC), flexible inputs (up to 128) and discrete outputs (up to 64). Connectors are logically compatible with the rau. be instructed to execute sequences of input/output commands to the RAU, similar to those performed during flight. This approximation of the experiment computer software is adequate to detect interface problems and prevent these from occurring during Spacelab payload integration. The SEID hardware is a microprocessor based system, utilizing an 8085 microprocessor with 6K of PROM and 4K of static RAM. The basic unit is augmented with an LSI-11 microcomputer to provide disk storage and a more dynamic environment for generation of control data. A simulation of the general monitoring loop is provided to emulate Spacelab system timing.

Kallus, R.↗

Software Process Assessment (SPA)

NASA's environment mirrors the changes taking place in the nation at large, i.e. workers are being asked to do more work with fewer resources. For software developers at NASA's Goddard Space Flight Center (GSFC), the effects of this change are that we must continue to produce quality code that is maintainable and reusable, but we must learn to produce it more efficiently and less expensively. To accomplish this goal, the Data Systems Technology Division (DSTD) at GSFC is trying a variety of both proven and state-of-the-art techniques for software development (e.g., object-oriented design, prototyping, designing for reuse, etc.). In order to evaluate the effectiveness of these techniques, the Software Process Assessment (SPA) program was initiated. SPA was begun under the assumption that the effects of different software development processes, techniques, and tools, on the resulting product must be evaluated in an objective manner in order to assess any benefits that may have accrued. SPA involves the collection and analysis of software product and process data. These data include metrics such as effort, code changes, size, complexity, and code readability. This paper describes the SPA data collection and analysis methodology and presents examples of benefits realized thus far by DSTD's software developers and managers.

Rosenberg, Linda H.↗

Crew Health and Performance Integrated Data Architecture (CHP-IDA) Project

BACKGROUND: Future Human Exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. A data architecture to support a new generation of technologies, employing advanced analytical and predictive modeling techniques, is needed to enable crew autonomy. OVERVIEW: The Crew Health and Performance Integrated Data Architecture (CHP-IDA) project funded by NASA’s Exploration Medical Integrated Product Team (XMIPT) is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. CHP-IDA provides a platform for common data models and Application Programming Interfaces to access, integrate, process, and display CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.). This will facilitate the increased situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the currently ongoing effort to develop and evaluate a path-to-flight concept of the CHP-IDA software and its core capabilities. Current integrations will be discussed, including analytics for Extravehicular Activity metabolic rate and data ingestion from a multi-functional integrated medical device. The presentation will also provide examples of scenarios used to demonstrate the CHP-IDA through human-in-the-loop test bed activities as well as examples of appropriate system performance metrics. DISCUSSION: Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting exploration medical capabilities. The CHP-IDA is a back-end data system providing core capabilities needed for timely and meaningful data insights across CHP domains to crew and remote personnel to enable increased crew autonomy. Future work includes collaboration with additional CHP domains, new technology integrations, and further demonstrations of the IDA within different vehicle and communication latency contexts. LEARNING OBJECTIVES 1. The audience will understand that the CHP-IDA is a back-end system, providing a platform to facilitate access, promote decision tools, and provide meaningful insights to crew and to remote stakeholders during exploration missions. 2. The audience will gain insight into human-centered research and activities used to discover CHP domain data needs and pain points and how this information is used to guide development of the IDA.

Exploration↗

Orbit Software Suite

Orbit Software Suite is used to support a variety of NASA/DM (Dependable Multiprocessor) mission planning and analysis activities on the IPS (Intrusion Prevention System) platform. The suite of Orbit software tools (Orbit Design and Orbit Dynamics) resides on IPS/Linux workstations, and is used to perform mission design and analysis tasks corresponding to trajectory/ launch window, rendezvous, and proximity operations flight segments. A list of tools in Orbit Software Suite represents tool versions established during/after the Equipment Rehost-3 Project.

Osgood, Cathy↗

Balloon Ascent: 3-D Simulation Tool for the Ascent and Float of High-Altitude Balloons

The BalloonAscent balloon flight simulation code represents a from-scratch development using Visual Basic 5 as the software platform. The simulation code is a transient analysis of balloon flight, predicting the skin and gas temperatures along with the 3-D position and velocity in a time and spatially varying environment. There are manual and automated controls for gas valving and the dropping of ballast. Also, there are many handy calculators, such as appropriate free lift, and steady-state thermal solutions with temperature gradients. The strength of this simulation model over others in the past is that the infrared environment is deterministic rather than guessed at. The ground temperature is specified along with the emissivity, which creates a ground level IR environment that is then partially absorbed as it travels upward through the atmosphere to the altitude of the balloon.

Farley, Rodger E.↗

Agile Development Methods for Space Operations

Main stream industry software development practice has gone from a traditional waterfall process to agile iterative development that allows for fast response to customer inputs and produces higher quality software at lower cost. How can we, the space ops community, adopt state of the art software development practice, achieve greater productivity at lower cost, and maintain safe and effective space flight operations? At NASA Ames, we are developing Mission Control Technologies Software, in collaboration with Johnson Space Center (JSC) and, more recently, the Jet Propulsion Laboratory (JPL).

Trimble, Jay↗

Ares I-X: On the Threshold of Exploration

Ares I-X, the first flight of the Ares I crew launch vehicle, is less than a year from launch. Ares I-X will test the flight characteristics of Ares I from liftoff to first stage separation and recovery. The flight also will demonstrate the computer hardware and software (avionics) needed to control the vehicle; deploy the parachutes that allow the first stage booster to land in the ocean safely; measure and control how much the rocket rolls during flight; test and measure the effects of first stage separation; and develop and try out new ground handling and rocket stacking procedures in the Vehicle Assembly Building (VAB) and first stage recovery procedures at Kennedy Space Center (KSC) in Florida. All Ares I-X major elements have completed their critical design reviews, and are nearing final fabrication. The first stage--four-segment solid rocket booster from the Space Shuttle inventory--incorporates new simulated forward structures to match the Ares I five-segment booster. The upper stage, Orion crew module, and launch abort system will comprise simulator hardware that incorporates developmental flight instrumentation for essential data collection during the mission. The upper stage simulator consists of smaller cylindrical segments, which were transported to KSC in fall 2008. The crew module and launch abort system simulator were shipped in December 2008. The first stage hardware, active roll control system (RoCS), and avionics components will be delivered to KSC in 2009. This paper will provide detailed statuses of the Ares I-X hardware elements as NASA's Constellation Program prepares for this first flight of a new exploration era in the summer of 2009.

Davis, Stephan R.↗

Parameter identification and modeling of longitudinal aerodynamics

Using a comprehensive flight test database and a parameter identification software program produced at NASA Ames Research Center, a math model of the longitudinal aerodynamics of the Harrier aircraft was formulated. The identification program employed the equation error method using multiple linear regression to estimate the nonlinear parameters. The formulated math model structure adhered closely to aerodynamic and stability/control theory, particularly with regard to compressibility and dynamic manoeuvring. Validation was accomplished by using a three degree-of-freedom nonlinear flight simulator with pilot inputs from flight test data. The simulation models agreed quite well with the measured states. It is important to note that the flight test data used for the validation of the model was not used in the model identification.

Aksteter, J. W.↗

Collaborative research on V/STOL control system/cockpit display tradeoffs under the NASA/MOD joint aeronautical program

Summarized here are activities that have taken place from 1979 to the present in a collaborative program between NASA Ames Research Center and the Royal Aerospace Establishment (now Defence Research Agency), Bedford on flight control system and cockpit display tradeoffs for low-speed and hover operations of future V/STOL aircraft. This program was created as Task 8A of the Joint Aeronautical Program between NASA in the United States and the Ministry of Defence (Procurement Executive) in the United Kingdom. The program was initiated based on a recognition by both parties of the strengths of the efforts of their counterparts and a desire to participate jointly in future simulation and flight experiments. In the ensuing years, teams of NASA and RAE engineers and pilots have participated in each other's simulation experiments to evaluate control and display concepts and define design requirements for research aircraft. Both organizations possess Harrier airframes that have undergone extensive modification to provide in-flight research capabilities in the subject areas. Both NASA and RAE have profited by exchanges of control/display concepts, design criteria, fabrication techniques, software development and validation, installation details, and ground and flight clearance techniques for their respective aircraft. This collaboration has permitted the two organizations to achieve jointly substantially more during the period than if they had worked independently. The two organizations are now entering the phase of flight research for the collaborative program as currently defined.

Franklin, J. A.↗

Role of simulation and emulation in the development of Shuttle-Centaur (STS-Centaur)

To support the task of integrating the Centaur liquid-fueled upper-stage space vehicle into the space shuttle program. A system to simulate and emulate the STS-Centaur avionic flight system and its supporting ground control and checkout equipment was selected and designated the systems integration facility (SIF). Located in San Diego, California, the SIF is composed of integrated simulators that form a composite control system complement to the STS-Centaur airborne and avionic support equipment. An off-line capability to verify the system design of the Centaur airborne support equipment (CASE) and the Centaur avionic flight system is provided as well as a realistic medium for the development and integration of ground checkout and airborne control software programs. Each simulator is composed of prototype hardware, where feasible, to maximize configuration likeness. Where emulated flight or ground hardware is used, it provides physical characteristics (loads, signals, etc.) equivalent to those of the flight hardware. The hardware and software implementation of the SIF are described.

Gordan, A. L.↗

Detailed design of a Ride Quality Augmentation System for commuter aircraft

The design of a Ride Quality Augmentation System (RQAS) for commuter aircraft is documented. The RQAS is designed for a Cessna 402B, an 8 passenger prop twin representative to this class of aircraft. The purpose of the RQAS is the reduction of vertical and lateral accelerations of the aircraft due to atmospheric turbulence by the application of active control. The detailed design of the hardware (the aircraft modifications, the Ride Quality Instrumentation System (RQIS), and the required computer software) is examined. The aircraft modifications, consisting of the dedicated control surfaces and the hydraulic actuation system, were designed at Cessna Aircraft by Kansas University-Flight Research Laboratory. The instrumentation system, which consist of the sensor package, the flight computer, a Data Acquisition System, and the pilot and test engineer control panels, was designed by NASA-Langley. The overall system design and the design of the software, both for flight control algorithms and ground system checkout are detailed. The system performance is predicted from linear simulation results and from power spectral densities of the aircraft response to a Dryden gust. The results indicate that both accelerations are possible.

Suikat, Reiner↗

Software Design Methodology Migration for a Distributed Ground System

The Marshall Space Flight Center's (MSFC) Payload Operations Center (POC) ground system has been developed and has evolved over a period of about 10 years. During this time the software processes have migrated from more traditional to more contemporary development processes. The new Software processes still emphasize requirements capture, software configuration management, design documenting, and making sure the products that have been developed are accountable to initial requirements. This paper will give an overview of how the Software Process have evolved highlighting the positives as well as the negatives. In addition, we will mention the COTS tools that have been integrated into the processes and how the COTS have provided value to the project .

Ritter, George↗

Evolution of a Reconfigurable Processing Platform for a Next Generation Space Software Defined Radio

The National Aeronautics and Space Administration (NASA)Harris Ka-Band Software Defined Radio (SDR) is the first, fully reprogrammable space-qualified SDR operating in the Ka-Band frequency range. Providing exceptionally higher data communication rates than previously possible, this SDR offers in-orbit reconfiguration, multi-waveform operation, and fast deployment due to its highly modular hardware and software architecture. Currently in operation on the International Space Station (ISS), this new paradigm of reconfigurable technology is enabling experimenters to investigate navigation and networking in the space environment.The modular SDR and the NASA developed Space Telecommunications Radio System (STRS) architecture standard are the basis for Harris reusable, digital signal processing space platform trademarked as AppSTAR. As a result, two new space radio products are a synthetic aperture radar payload and an Automatic Detection Surveillance Broadcast (ADS-B) receiver. In addition, Harris is currently developing many new products similar to the Ka-Band software defined radio for other applications. For NASAs next generation flight Ka-Band radio development, leveraging these advancements could lead to a more robust and more capable software defined radio.The space environment has special considerations different from terrestrial applications that must be considered for any system operated in space. Each space mission has unique requirements that can make these systems unique. These unique requirements can make products that are expensive and limited in reuse. Space systems put a premium on size, weight and power. A key trade is the amount of reconfigurability in a space system. The more reconfigurable the hardware platform, the easier it is to adapt to the platform to the next mission, and this reduces the amount of non-recurring engineering costs. However, the more reconfigurable platforms often use more spacecraft resources. Software has similar considerations to hardware. Having an architecture standard promotes reuse of software and firmware. Space platforms have limited processor capability, which makes the trade on the amount of amount of flexibility paramount.

Telecommunication↗

Schedule Factors Associated with the Use of Controlled Rest in a Long-Haul Airline

Controlled Rest (CR) refers to a short, voluntary nap opportunity taken by pilots on the flight deck as a countermeasure to unanticipated sleepiness in flight. This study explores the profile of CR use in a long-haul commercial airline. Forty-four pilots wore actiwatches and filled in an application-based sleep/work diary for approximately 2 weeks. After merging sleep diary, actigraphy, and schedule data, complete records were analyzed from 240 flights. Sleep was estimated during CR intervals using the Philips Actiware 6.0.9 (Bend, OR) software with wake threshold set to medium. Timing of sleep periods and flight schedules were analyzed relative to home-base time. A mixed-effects binary logistics regression was used to analyze the impact of schedule factors on CR. Preliminary analyses revealed that CR was taken on 45% (n=107) of flights. Average sleep duration within these rest periods was estimated as 24.8 ± 16.1 minutes. CR was more frequent on return flights (arriving at home-base; 58%, n=69) vs. outbound flights (departing from home-base, 31%, n=38; p<0.001). There was no difference for direction of travel (eastbound: 49%, n= 56; westbound: 40%, n= 44; northbound/southbound: 50%, n=7; p=0.272). CR was more frequent on 2-pilot flights (62%, n=81) compared to augmented crew flights (24%, n=26; p<0.001). Of note, 21% (n=23) of augmented flights contained both CR and Bunk Rest. CR was more frequent on flights <10h duration (<10h: 59%, n=78; >10h: 27%, n=29; p<0.001). Flights departing between 12:00h-19:59h (25%, n=23; p<0.026) had the lowest frequency of CR. Data from this airline show that CR is most commonly used as a countermeasure to sleepiness on return, unaugmented, <10h duration, and nighttime flights. The direction of travel did not influence the use of CR. Future studies are required to determine generalizability of these results to other airlines.

Hilditch, Cassie↗

Towards a general object-oriented software development methodology

An object is an abstract software model of a problem domain entity. Objects are packages of both data and operations of that data (Goldberg 83, Booch 83). The Ada (tm) package construct is representative of this general notion of an object. Object-oriented design is the technique of using objects as the basic unit of modularity in systems design. The Software Engineering Laboratory at the Goddard Space Flight Center is currently involved in a pilot program to develop a flight dynamics simulator in Ada (approximately 40,000 statements) using object-oriented methods. Several authors have applied object-oriented concepts to Ada (e.g., Booch 83, Cherry 85). It was found that these methodologies are limited. As a result a more general approach was synthesized with allows a designer to apply powerful object-oriented principles to a wide range of applications and at all stages of design. An overview is provided of this approach. Further, how object-oriented design fits into the overall software life-cycle is considered.

Seidewitz, ED↗

A software engineering approach to expert system design and verification

Software engineering design and verification methods for developing expert systems are not yet well defined. Integration of expert system technology into software production environments will require effective software engineering methodologies to support the entire life cycle of expert systems. The software engineering methods used to design and verify an expert system, RENEX, is discussed. RENEX demonstrates autonomous rendezvous and proximity operations, including replanning trajectory events and subsystem fault detection, onboard a space vehicle during flight. The RENEX designers utilized a number of software engineering methodologies to deal with the complex problems inherent in this system. An overview is presented of the methods utilized. Details of the verification process receive special emphasis. The benefits and weaknesses of the methods for supporting the development life cycle of expert systems are evaluated, and recommendations are made based on the overall experiences with the methods.

Bochsler, Daniel C.↗

The VISAR Process

The Video Image Stabilization And Registration (VISAR) process is an award winning video image processing software developed at NASA's Marshall Space Flight Center. VISAR has a wide variety of application areas where the refinement of digital video is needed. It is used to correct jitter, rotation, and zoom effects by registering and processing on individual image captures that are a part of normal video capturing. Its most prominent uses were the 1996 Olympic Bombing case and in identifying Saddam Hussein during the Iraq war. Based on first-hand knowledge, this paper describes the VISAR process, which consists of several steps designed to refine digital video using VISAR software. The process determines the differences between two video images so that one, or both, of the images can be changed in ways that make them match as well as possible. Corrections include changes in position (horizontal and vertical image shifts), changes in orientation (image rotation), and changes in magnification (image zoom). While much of the VISAR process is automated, in its current embodiment it requires the user to initially identify the area of interest and to reset a threshold parameter if the default gives unacceptable results. The basic process that is used is an old tried and true method that determines how well the two images match. This process is called cross-correlation. It gives a single number, the correlation coefficient, that is equal to 1.0 if the images are perfectly matched, is equal to 0.0 if the images have nothing in common, and is equal to -1.0 if one image is the negative of the other. This basic process is used by many image stabilization methods. With VISAR we use it in a manner that provides statistical information needed to best determine orientation and magnification.

Hathaway, David↗

A methodology for validating software reliability

A significant problem associated with fault tolerant computer system design is how to insure that there are no embedded software errors, so that an avionics computer system meets the required reliability level. To accomplish this, it is necessary to associate a 'probability of failure' with the operational flight program. It would be more correct to say that the probability of excitation of existing latent design errors within the program is required. In this sense, latent software errors are like latent hardware faults, and techniques that were previously used to measure the probability of failure of hardware due to fault latency can be used to measure the probability of failure of the software. A methodology was developed and applied to a flight control program that was known to operate in a well defined environment. The results indicated that the technique could be used to provide a final validation of the software to a specified reliability level and to evaluate the role of flight test in software validation.

Swern, Frederic L.↗