Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software testing”

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,783 records · Page 99
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Spacecraft Avionics Software Development Then and Now: Different but the Same

NASA has always been in the business of balancing new technologies and techniques to achieve human space travel objectives. NASA s historic Software Production Facility (SPF) was developed to serve complex avionics software solutions during an era dominated by mainframes, tape drives, and lower level programming languages. These systems have proven themselves resilient enough to serve the Shuttle Orbiter Avionics life cycle for decades. The SPF and its predecessor the Software Development Lab (SDL) at NASA s Johnson Space Center (JSC) hosted flight software (FSW) engineering, development, simulation, and test. It was active from the beginning of Shuttle Orbiter development in 1972 through the end of the shuttle program in the summer of 2011 almost 40 years. NASA s Kedalion engineering analysis lab is on the forefront of validating and using many contemporary avionics HW/SW development and integration techniques, which represent new paradigms to NASA s heritage culture in avionics software engineering. Kedalion has validated many of the Orion project s HW/SW engineering techniques borrowed from the adjacent commercial aircraft avionics environment, inserting new techniques and skills into the Multi-Purpose Crew Vehicle (MPCV) Orion program. Using contemporary agile techniques, COTS products, early rapid prototyping, in-house expertise and tools, and customer collaboration, NASA has adopted a cost effective paradigm that is currently serving Orion effectively. This paper will explore and contrast differences in technology employed over the years of NASA s space program, due largely to technological advances in hardware and software systems, while acknowledging that the basic software engineering and integration paradigms share many similarities.

Mangieri, Mark L.↗
NASA NTRS2017

DANTi: Detect and Avoid iN The Cockpit

Mid-air collision risk continues to be a concern for manned aircraft operations, especially near busy non-towered airports. The use of Detect and Avoid (DAA) technologies and draft standards developed for unmanned aircraft systems (UAS), either alone or in combination with other collision avoidance technologies, may be useful in mitigating this collision risk for manned aircraft. This paper describes a NASA research effort known as DANTi (DAA iN The Cockpit), including the initial development of the concept of use, a software prototype, and results from initial flight tests conducted with this prototype. The prototype used a single Automatic Dependent Surveillance - Broadcast (ADS-B) traffic sensor and the own aircraft's position, track, heading and air data information, along with NASA-developed DAA software to display traffic alerts and maneuver guidance to manned aircraft pilots on a portable tablet device. Initial flight tests with the prototype showed a successful DANTi proof-of-concept, but also demonstrated that the traffic separation parameter set specified in the RTCA SC-228 Phase I DAA MOPS may generate excessive false alerts during traffic pattern operations. Several parameter sets with smaller separation values were also tested in flight, one of which yielded more timely alerts for the maneuvers tested. Results from this study may further inform future DANTi efforts as well as Phase II DAA MOPS development.

Chamberlain, James↗
NASA NTRS1992

Investigations of rhesus monkey video-task performance: evidence for enrichment

We have developed the Language Research Center's Computerized Test System (LRC-CTS) for psychological research. Basically, the LRC-CTS is a battery of software tasks--computerized versions of many of the classic testing paradigms of cognitive and comparative psychology--and the hardware required to administer them. An XT- or 386-compatible computer is connected to a color monitor, onto which computer-generated stimuli are presented. Sound feedback is delivered through an external speaker/amplifier, and a joystick is used as an input device. The animals reach through the mesh of their home cages to manipulate the joystick, which causes isomorphic movements of a cursor on the screen thereby allowing animals to respond according to the varied demands of the tasks. Correct responses are rewarded with a fruit-flavored chow pellet. Using this technology, we have trained and tested rhesus monkeys, a variety of apes, human adults, and normally developing or mentally retarded human children. Other labs using the LRC-CTS are beginning to report encouraging results with other monkey species as well. From this research, a number of interesting and important psychological findings have resulted. In the present paper, however, evidence will be reviewed which suggests that the LRC-CTS is an effective means of providing environmental enrichment to singly housed rhesus monkeys.

Non-NASA Center↗
NASA NTRS1998

Integration of the Remote Agent for the NASA Deep Space One Autonomy Experiment

This paper describes the integration of the Remote Agent (RA), a spacecraft autonomy system which is scheduled to control the Deep Space 1 spacecraft during a flight experiment in 1999. The RA is a reusable, model-based autonomy system that is quite different from software typically used to control an aerospace system. We describe the integration challenges we faced, how we addressed them, and the lessons learned. We focus on those aspects of integrating the RA that were either easier or more difficult than integrating a more traditional large software application because the RA is a model-based autonomous system. A number of characteristics of the RA made integration process easier. One example is the model-based nature of RA. Since the RA is model-based, most of its behavior is not hard coded into procedural program code. Instead, engineers specify high level models of the spacecraft's components from which the Remote Agent automatically derives correct system-wide behavior on the fly. This high level, modular, and declarative software description allowed some interfaces between RA components and between RA and the flight software to be automatically generated and tested for completeness against the Remote Agent's models. In addition, the Remote Agent's model-based diagnosis system automatically diagnoses when the RA models are not consistent with the behavior of the spacecraft. In flight, this feature is used to diagnose failures in the spacecraft hardware. During integration, it proved valuable in finding problems in the spacecraft simulator or flight software. In addition, when modifications are made to the spacecraft hardware or flight software, the RA models are easily changed because they only capture a description of the spacecraft. one does not have to maintain procedural code that implements the correct behavior for every expected situation. On the other hand, several features of the RA made it more difficult to integrate than typical flight software. For example, the definition of correct behavior is more difficult to specify for a system that is expected to reason about and flexibly react to its environment than for a traditional flight software system. Consequently, whenever a change is made to the RA it is more time consuming to determine if the resulting behavior is correct. We conclude the paper with a discussion of future work on the Remote Agent as well as recommendations to ease integration of similar autonomy projects.

Dorais, Gregory A.↗
DOE OSTI2021

Uncertainty Analysis and Software Verification

Uncertainty analyses are an important part of calibrations and testing. They allow researchers insight on how to reduce and mitigate errors in testing. Each device used in testing introduces error in a system, as well as other sources such as environmental conditions, electronics, analog to digital, and random errors. Each source is carefully examined to identify how much error it introduces to a system. These sources are then combined using various methods of uncertainty calculations. To verify and validate software, a manual calculation is required to ensure the software is performing as intended. Using Excel to verify the calculations, we can identify discrepancies within the software. The root of the sum of the squares uncertainty (RSS) is used to find the combined uncertainty of a device at one and two standard deviations of the mean. Calibrations on accelerometers are performed using a vibration system along with a back-toback reference accelerometer. The vibration system takes a reference point at 100Hz frequency at 10g amplitude. The sensitivities are collected at each dialed in frequency. The sensitivity of the device represents the electrical output of the UUT (mV, pC, etc.) per unit of acceleration (g). The full history of sensitivities of selected accelerometers are used to find the averaged, standard deviation, and uncertainty of the device at each frequency tested. The uncertainty calculations from excel and the software are then compared.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2026

RAPIDS2: A SciDAC Institute for Computer Science, Data, and Artificial Intelligence (University of Delaware)

This report summarizes the activities, technical accomplishments, and outcomes of the RAPIDS2 Institute project at the University of Delaware (UD). The RAPIDS2 Institute was a large multi-institution project with the objective of assisting SciDAC and Office of Science application teams in the use of DOE supercomputing resources to achieve scientific breakthroughs. The UD team contributed to this effort through work on formal software verification. This thrust aims to reduce software developer time and effort, especially regarding debugging and testing, and to increase confidence in the correctness of the results computed by the software.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1982

Space Telescope Pointing Control System software

The Space Telescope Pointing Control System software is in the advanced development stage, having been tested on both the airbearing and the static simulator. The overall structure of the software is discussed, along with timing and sizing evaluations. The interaction between the controls analysts and software designer is described.

Dougherty, H.↗
NASA NTRS2011

Full-Scaled Advanced Systems Testbed: Ensuring Success of Adaptive Control Research Through Project Lifecycle Risk Mitigation

The National Aeronautics and Space Administration's Dryden Flight Research Center completed flight testing of adaptive controls research on the Full-Scale Advance Systems Testbed (FAST) in January of 2011. The research addressed technical challenges involved with reducing risk in an increasingly complex and dynamic national airspace. Specific challenges lie with the development of validated, multidisciplinary, integrated aircraft control design tools and techniques to enable safe flight in the presence of adverse conditions such as structural damage, control surface failures, or aerodynamic upsets. The testbed is an F-18 aircraft serving as a full-scale vehicle to test and validate adaptive flight control research and lends a significant confidence to the development, maturation, and acceptance process of incorporating adaptive control laws into follow-on research and the operational environment. The experimental systems integrated into FAST were designed to allow for flexible yet safe flight test evaluation and validation of modern adaptive control technologies and revolve around two major hardware upgrades: the modification of Production Support Flight Control Computers (PSFCC) and integration of two, fourth-generation Airborne Research Test Systems (ARTS). Post-hardware integration verification and validation provided the foundation for safe flight test of Nonlinear Dynamic Inversion and Model Reference Aircraft Control adaptive control law experiments. To ensure success of flight in terms of cost, schedule, and test results, emphasis on risk management was incorporated into early stages of design and flight test planning and continued through the execution of each flight test mission. Specific consideration was made to incorporate safety features within the hardware and software to alleviate user demands as well as into test processes and training to reduce human factor impacts to safe and successful flight test. This paper describes the research configuration, experiment functionality, overall risk mitigation, flight test approach and results, and lessons learned of adaptive controls research of the Full-Scale Advanced Systems Testbed.

Pavlock, Kate M.↗
NASA NTRSDate not supplied

Feature-Guided Analysis of Neural Networks

Applying standard software engineering practices to neural networks is challenging due to the lack of high-level abstractions describing a neural network’s behavior. To address this challenge, we propose to extract high-level task-specific features from the neural network internal representation, based on monitoring the neural network activations.The extracted feature representations can serve as a link to high-level requirements and can be leveraged to enable fundamental software engineering activities, such as automated testing, debugging, requirements analysis, and formal verification, leading to better engineering of neural networks. Using two case studies, we present initial empirical evidence demonstrating the feasibility of our ideas.

Features↗
NASA NTRS2024

Historical Aerospace Software Errors Categorized to Influence Fault Tolerance

Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in mission or safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes a set of 55 historic aerospace software error incidents from 1962 to 2023 to determine trends of how and where automation is most likely to fail, behaving unexpectedly. A distinction between software producing unexpected (erroneous) output versus no output (failsilent) is introduced. Of the historical incidents analyzed, 85% were from software producing wrong output rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and not reliable to recover from silent failures. Error origin was within the code/logic itself in 58% of cases, 16% from configurable data, 15% from unexpected sensor input, and 11% from command/operator input. A substantial forty percent (40%) of unexpected software behavior was indicated by the absence of code, arising from unanticipated situations and missing requirements, and 16% of incidents were subjectively deemed “unknown-unknowns”. No incidents were found to be the result of programming language, compiler, tool, or operating system; and only sixteen percent (16%) of all incidents were considered errors traditional computer science/programming in nature. These findings indicate that for fault tolerance, erroneous automation behavior must be a primary consideration especially at critical moments, and reboot recoverability may not be viable. Special care should be taken to validate configurable data and commands prior to use. “Test-like-you-fly”, including hardware-in-the-loop combined with robust off-nominal testing should be used to uncover missing logic arising from unanticipated situations not covered by requirements alone. This study uniquely focuses on manifestations of unexpected flight software behavior, independent of ultimate root cause. We characterize software error behavior and origin to improve software design, test, and operations for resilience to the most common manifestations, and provide a rich dataset for further study.

Aerospace↗
NASA NTRS2012

Development And Test of A Digitally Steered Antenna Array for The Navigator GPS Receiver

Global Positioning System (GPS)-based navigation has become common for low-Earth orbit spacecraft as the signal environment is similar to that on the Earth s surface. The situation changes abruptly, however, for spacecraft whose orbital altitudes exceed that of the GPS constellation. Visibility is dramatically reduced and signals that are present may be very weak and more susceptible to interference. GPS receivers effective at these altitudes require increased sensitivity, which often requires a high-gain antenna. Pointing such an antenna can pose a challenge. One efficient approach to mitigate these problems is the use of a digitally steered antenna array. Such an antenna can optimally allocate gain toward desired signal sources and away from interferers. This paper presents preliminary results in the development and test of a digitally steered antenna array for the Navigator GPS research program at NASA s Goddard Space Flight Center. In particular, this paper highlights the development of an array and front-end electronics, the development and test of a real-time software GPS receiver, and implementation of three beamforming methods for combining the signals from the array. Additionally, this paper discusses the development of a GPS signal simulator which produces digital samples of the GPS L1C/A signals as they would be received by an arbitrary antenna array configuration. The simulator models transmitter and receiver dynamics, near-far and multipath interference, and has been a critical component in both the development and test of the GPS receiver. The GPS receiver system was tested with real and simulated GPS signals. Preliminary results show that performance improvement was achieved in both the weak signal and interference environments, matching analytical predictions. This paper summarizes our initial findings and discusses the advantages and limitations of the antenna array and the various beamforming methods.

Pinto, Heitor David↗
DOE OSTI2014

SU-E-T-80: Comparison of Fluence-Based RapidArc QAs Using EPID and MapCHECK 2

Purpose: To compare the Varian aS-1000 EPID imager to the isocentrically mounted MapCHECK 2 diode array for RapidArc QAs as a function of photon beam energy. Methods: A Varian TrueBeam STx with an aS-1000 digital imaging panel was used to acquire RapidArc QA images for 13 patient plans; each plan QA was performed at 6, 8, 10 and 15MV energies. The Portal Dose Image Prediction algorithm in the Varian Eclipse treatment planning system (TPS) was used to create the comparison image for the EPID acquisition. A Sun Nuclear MapCHECK 2 diode array on an isocentric mounting fixture with 5 cm water-equivalent buildup was also used for the RapidArc QAs. A composite dose plane was taken from the Eclipse TPS for comparison to the MapCHECK 2 measurements. A gamma test was implemented in the Sun Nuclear Patient software with 10% threshold and absolute comparison for both QA methods. The two-tailed paired t-test was employed to analyze the statistical significance between two methods at the 95% confidence level. Results: The average gamma passing rates were greater than 95% at 3%/3mm using both methods for all four energies. The average passing rates were within 2.5% and 1.1% of each other when analyzed at 2%/2mm and 3%/3mm conditions, respectively. The EPID passing rates were somewhat better than the MapCHECK 2 when analyzed at 1%/1mm condition; this difference decreased with increasing energy (9.1% at 6MV to 2.7% at 15MV). The differences were not statistically significant for all criteria and energies (p-value ã 0.05). Conclusion: EPID-based RapidArc QA results are comparable to MapCHECK 2 when using 3%/3mm criteria at all four energies. EPID-based QA shows potential for being the superior device under strict gamma criteria.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2022

Biomaniac

Los Alamos National Laboratory researchers are developing a machine-learning based algorithm to revolutionize how biopolymers are designed and optimized. BioManIAC is a software platform that fills the gaps in data to gain insight into new potential polymer properties without making and testing them. Polymer engineers are able to use BioManIAC software to extrapolate and tune new biopolymer properties that allow the user to create small smart libraries, rather than largescale trial and error testing. This targeted design is expected to improve both time to market and R&D expenditure, as well as the resulting mechanical properties of biopolymers, enabling for more direct competition with traditional petroleum-based polymers. Los Alamos is seeking partners to further validate our software platform.

36 MATERIALS SCIENCE↗
DOE OSTI2022

Experiences with Porting the FLASH Code to Ookami, an HPE Apollo 80 A64FX Platform

We present initial experiences with running the community simulation code FLASH, developed at the University of Chicago for multi-scale multi-physics applications, on Ookami, a technology testbed featuring the A64FX processor developed by Fujitsu. Our effort focused largely on running FLASH “right out of the box” to see which combinations of compilers and software implementations (e.g. MPI) allowed the code to run with minimal modification. FLASH was one application in a larger effort to deploy Ookami; it served as a test for different versions of newly installed software, and as a cornerstone for the FAQ page of the Ookami website. Here, we report on our results with different compilers and other software, along with our initial scaling results and attempts to utilize the A64FX’s SVE instructions and NUMA architecture. We found that FLASH readily ran with different compilers and MPI implementations, and showed the expected good scaling with no turning. However, more work must be done to fully take advantage of the A64FX’s architectural features and produce a significant speedup for FLASH on Ookami.

79 ASTRONOMY AND ASTROPHYSICS↗
NASA NTRS2012

Robotic Lunar Lander Development Status

NASA Marshall Space Flight Center and John Hopkins University Applied Physics Laboratory have developed several mission concepts to place scientific and exploration payloads ranging from 10 kg to more than 200 kg on the surface of the moon. The mission concepts all use a small versatile lander that is capable of precision landing. The results to date of the lunar lander development risk reduction activities including high pressure propulsion system testing, structure and mechanism development and testing, and long cycle time battery testing will be addressed. The most visible elements of the risk reduction program are two fully autonomous lander flight test vehicles. The first utilized a high pressure cold gas system (Cold Gas Test Article) with limited flight durations while the subsequent test vehicle, known as the Warm Gas Test Article, utilizes hydrogen peroxide propellant resulting in significantly longer flight times and the ability to more fully exercise flight sensors and algorithms. The development of the Warm Gas Test Article is a system demonstration and was designed with similarity to an actual lunar lander including energy absorbing landing legs, pulsing thrusters, and flight-like software implementation. A set of outdoor flight tests to demonstrate the initial objectives of the WGTA program was completed in Nov. 2011, and will be discussed.

Ballard, Benjamin↗
NASA NTRS2012

NASA's Robotic Lunar Lander Development Program

NASA Marshall Space Flight Center and the Johns Hopkins University Applied Physics Laboratory have developed several mission concepts to place scientific and exploration payloads ranging from 10 kg to more than 200 kg on the surface of the moon. The mission concepts all use a small versatile lander that is capable of precision landing. The results to date of the lunar lander development risk reduction activities including high pressure propulsion system testing, structure and mechanism development and testing, and long cycle time battery testing will be addressed. The most visible elements of the risk reduction program are two fully autonomous lander flight test vehicles. The first utilized a high pressure cold gas system (Cold Gas Test Article) with limited flight durations while the subsequent test vehicle, known as the Warm Gas Test Article, utilizes hydrogen peroxide propellant resulting in significantly longer flight times and the ability to more fully exercise flight sensors and algorithms. The development of the Warm Gas Test Article is a system demonstration and was designed with similarity to an actual lunar lander including energy absorbing landing legs, pulsing thrusters, and flight-like software implementation. A set of outdoor flight tests to demonstrate the initial objectives of the WGTA program was completed in Nov. 2011, and will be discussed.

Ballard, Benjamin W.↗
NASA NTRS1995

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

Software Verification of Orion Cockpit Displays

NASA's latest spacecraft Orion is in the development process of taking humans deeper into space. Orion is equipped with three main displays to monitor and control the spacecraft. To ensure the software behind the glass displays operates without faults, rigorous testing is needed. To conduct such testing, the Rapid Prototyping Lab at NASA's Johnson Space Center along with the University of Texas at Tyler employed a software verification tool, EggPlant Functional by TestPlant. It is an image based test automation tool that allows users to create scripts to verify the functionality within a program. A set of edge key framework and Common EggPlant Functions were developed to enable creation of scripts in an efficient fashion. This framework standardized the way to code and to simulate user inputs in the verification process. Moreover, the Common EggPlant Functions can be used repeatedly in verification of different displays.

Biswas, M. A. Rafe↗