Search NASA⌕ Search

SEARCH · Search NASA

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 271 records · Page 15

Software control program for 25 kW breadboard testing

A data acquisition software program developed to operate in conjunction with the automated control system of the 25 kW PM Electric Power System Breadboard Test facility is described. The proram provides limited interactive control of the breadboard test while acquiring data and monitoring parameters, allowing unattended continuous operation. The breadboard test facility has two positions for operating separate configurations. The main variable in each test setup is the high voltage Ni-Cd battery.

Pajak, J. A.↗

Generalized Symbolic Execution for Model Checking and Testing

Modern software systems, which often are concurrent and manipulate complex data structures must be extremely reliable. We present a novel framework based on symbolic execution, for automated checking of such systems. We provide a two-fold generalization of traditional symbolic execution based approaches: one, we define a program instrumentation, which enables standard model checkers to perform symbolic execution; two, we give a novel symbolic execution algorithm that handles dynamically allocated structures (e.g., lists and trees), method preconditions (e.g., acyclicity of lists), data (e.g., integers and strings) and concurrency. The program instrumentation enables a model checker to automatically explore program heap configurations (using a systematic treatment of aliasing) and manipulate logical formulae on program data values (using a decision procedure). We illustrate two applications of our framework: checking correctness of multi-threaded programs that take inputs from unbounded domains with complex structure and generation of non-isomorphic test inputs that satisfy a testing criterion. Our implementation for Java uses the Java PathFinder model checker.

Khurshid, Sarfraz↗

Factors That Affect Software Testability

Software faults that infrequently affect software's output are dangerous. When a software fault causes frequent software failures, testing is likely to reveal the fault before the software is releases; when the fault remains undetected during testing, it can cause disaster after the software is installed. A technique for predicting whether a particular piece of software is likely to reveal faults within itself during testing is found in [Voas91b]. A piece of software that is likely to reveal faults within itself during testing is said to have high testability. A piece of software that is not likely to reveal faults within itself during testing is said to have low testability. It is preferable to design software with higher testabilities from the outset, i.e., create software with as high of a degree of testability as possible to avoid the problems of having undetected faults that are associated with low testability. Information loss is a phenomenon that occurs during program execution that increases the likelihood that a fault will remain undetected. In this paper, I identify two brad classes of information loss, define them, and suggest ways of predicting the potential for information loss to occur. We do this in order to decrease the likelihood that faults will remain undetected during testing.

Voas, Jeffrey M.↗

NASA Data Acquisition System Software Development for Rocket Propulsion Test Facilities

Current NASA propulsion test facilities include Stennis Space Center in Mississippi, Marshall Space Flight Center in Alabama, Plum Brook Station in Ohio, and White Sands Test Facility in New Mexico. Within and across these centers, a diverse set of data acquisition systems exist with different hardware and software platforms. The NASA Data Acquisition System (NDAS) is a software suite designed to operate and control many critical aspects of rocket engine testing. The software suite combines real-time data visualization, data recording to a variety formats, short-term and long-term acquisition system calibration capabilities, test stand configuration control, and a variety of data post-processing capabilities. Additionally, data stream conversion functions exist to translate test facility data streams to and from downstream systems, including engine customer systems. The primary design goals for NDAS are flexibility, extensibility, and modularity. Providing a common user interface for a variety of hardware platforms helps drive consistency and error reduction during testing. In addition, with an understanding that test facilities have different requirements and setups, the software is designed to be modular. One engine program may require real-time displays and data recording; others may require more complex data stream conversion, measurement filtering, or test stand configuration management. The NDAS suite allows test facilities to choose which components to use based on their specific needs. The NDAS code is primarily written in LabVIEW, a graphical, data-flow driven language. Although LabVIEW is a general-purpose programming language; large-scale software development in the language is relatively rare compared to more commonly used languages. The NDAS software suite also makes extensive use of a new, advanced development framework called the Actor Framework. The Actor Framework provides a level of code reuse and extensibility that has previously been difficult to achieve using LabVIEW. The

Herbert, Phillip W., Sr.↗

Stress testing of digital flight-control system software

A technique for dynamically testing digital flight-control system software on a module-by-module basis is described. Each test module is repetitively executed faster than real-time with an exhaustive input sequence. Outputs of the test module are compared with outputs generated by an alternate, simpler implementation for the same input data. Discrepancies between the two sets of output indicate the possible presence of a software error. The results of an implementation of this technique in the Digital Flight-Control System Software Verification Laboratory are discussed.

Rajan, N.↗

Evaluation of Open-Source Hard Real Time Software Packages

Reliable software is, at times, hard to find. No piece of software can be guaranteed to work in every situation that may arise during its use here at Glenn Research Center or in space. The job of the Software Assurance (SA) group in the Risk Management Office is to rigorously test the software in an effort to ensure it matches the contract specifications. In some cases the SA team also researches new alternatives for selected software packages. This testing and research is an integral part of the department of Safety and Mission Assurance. Real Time operation in reference to a computer system is a particular style of handing the timing and manner with which inputs and outputs are handled. A real time system executes these commands and appropriate processing within a defined timing constraint. Within this definition there are two other classifications of real time systems: hard and soft. A soft real time system is one in which if the particular timing constraints are not rigidly met there will be no critical results. On the other hand, a hard real time system is one in which if the timing constraints are not met the results could be catastrophic. An example of a soft real time system is a DVD decoder. If the particular piece of data from the input is not decoded and displayed to the screen at exactly the correct moment nothing critical will become of it, the user may not even notice it. However, a hard real time system is needed to control the timing of fuel injections or steering on the Space Shuttle; a delay of even a fraction of a second could be catastrophic in such a complex system. The current real time system employed by most NASA projects is Wind River's VxWorks operating system. This is a proprietary operating system that can be configured to work with many of NASA s needs and it provides very accurate and reliable hard real time performance. The down side is that since it is a proprietary operating system it is also costly to implement. The prospect of replacing this somewhat costly implementation is the focus of one of the SA group s current research projects. The explosion of open source software in the last ten years has led to the development of a multitude of software solutions which were once only produced by major corporations. The benefits of these open projects include faster release and bug patching cycles as well as inexpensive if not free software solutions. The main packages for hard real time solutions under Linux are Real Time Application Interface (RTAI) and two varieties of Real Time Linux (RTL), RTLFree and RTLPro. During my time here at NASA I have been testing various hard real time solutions operating as layers on the Linux Operating System. All testing is being run on an Intel SBC 2590 which is a common embedded hardware platform. The test plan was provided to me by the Software Assurance group at the start of my internship and my job has been to test the systems by developing and executing the test cases on the hardware. These tests are constructed so that the Software Assurance group can get hard test data for a comparison between the open source and proprietary implementations of hard real time solutions.

Mattei, Nicholas S.↗

Computer-controlled environmental test systems - Criteria for selection, installation, and maintenance.

Applications for presently marketed, new computer-controlled environmental test systems are suggested. It is shown that capital costs of these systems follow an exponential cost function curve that levels out as additional applications are implemented. Some test laboratory organization changes are recommended in terms of new personnel requirements, and facility modification are considered in support of a computer-controlled test system. Software for computer-controlled test systems are discussed, and control loop speed constraints are defined for real-time control functions. Suitable input and output devices and memory storage device tradeoffs are also considered.

Chapman, C. P.↗

NASA Tech Briefs, September 2003

Topics include: Oxygen-Partial-Pressure Sensor for Aircraft Oxygen Mask; Three-Dimensional Venturi Sensor for Measuring Extreme Winds; Swarms of Micron-Sized Sensors; Monitoring Volcanoes by Use of Air-Dropped Sensor Packages; Capacitive Sensors for Measuring Masses of Cryogenic Fluids; UHF Microstrip Antenna Array for Synthetic- Aperture Radar; Multimode Broad-Band Patch Antennas; 164-GHz MMIC HEMT Frequency Doubler; GPS Position and Heading Circuitry for Ships; Software for Managing Parametric Studies; Software Aids Visualization of Computed Unsteady Flow; Software for Testing Electroactive Structural Components; Advanced Software for Analysis of High-Speed Rolling-Element Bearings; Web Program for Development of GUIs for Cluster Computers; XML-Based Generator of C++ Code for Integration With GUIs; Oxide Protective Coats for Ir/Re Rocket Combustion Chambers; Simplified Waterproofing of Aerogels; Improved Thermal-Insulation Systems for Low Temperatures; Device for Automated Cutting and Transfer of Plant Shoots; Extension of Liouville Formalism to Postinstability Dynamics; Advances in Thrust-Based Emergency Control of an Airplane; Ultrasonic/Sonic Mechanisms for Drilling and Coring; Exercise Device Would Exert Selectable Constant Resistance; Improved Apparatus for Measuring Distance Between Axles; Six Classes of Diffraction-Based Optoelectronic Instruments; Modernizing Fortran 77 Legacy Codes; Active State Model for Autonomous Systems; Shields for Enhanced Protection Against High-Speed Debris; Scaling of Two-Phase Flows to Partial-Earth Gravity; Neutral-Axis Springs for Thin-Wall Integral Boom Hinges.

Source record↗

Software survey for the avionics test bed

A survey was conducted to itemize software programs that could possibly be used in the development of an avionics test bed for shuttle attached or autonomous large space structures. The results of this survey are presented. Each program is described on a standard form.

Cobb, J. M.↗

Detection and avoidance of errors in computer software

The acceptance test errors of a computer software project to determine if the errors could be detected or avoided in earlier phases of development. GROAGSS (Gamma Ray Observatory Attitude Ground Support System) was selected as the software project to be examined. The development of the software followed the standard Flight Dynamics Software Development methods. GROAGSS was developed between August 1985 and April 1989. The project is approximately 250,000 lines of code of which approximately 43,000 lines are reused from previous projects. GROAGSS had a total of 1715 Change Report Forms (CRFs) submitted during the entire development and testing. These changes contained 936 errors. Of these 936 errors, 374 were found during the acceptance testing. These acceptance test errors were first categorized into methods of avoidance including: more clearly written requirements; detail review; code reading; structural unit testing; and functional system integration testing. The errors were later broken down in terms of effort to detect and correct, class of error, and probability that the prescribed detection method would be successful. These determinations were based on Software Engineering Laboratory (SEL) documents and interviews with the project programmers. A summary of the results of the categorizations is presented. The number of programming errors at the beginning of acceptance testing can be significantly reduced. The results of the existing development methodology are examined for ways of improvements. A basis is provided for the definition is a new development/testing paradigm. Monitoring of the new scheme will objectively determine its effectiveness on avoiding and detecting errors.

Kinsler, Les↗

Flight-Tested Prototype of BEAM Software

Researchers at JPL have completed a software prototype of BEAM (Beacon-based Exception Analysis for Multi-missions) and successfully tested its operation in flight onboard a NASA research aircraft. BEAM (see NASA Tech Briefs, Vol. 26, No. 9; and Vol. 27, No. 3) is an ISHM (Integrated Systems Health Management) technology that automatically analyzes sensor data and classifies system behavior as either nominal or anomalous, and further characterizes anomalies according to strength, duration, and affected signals. BEAM (see figure) can be used to monitor a wide variety of physical systems and sensor types in real time. In this series of tests, BEAM monitored the engines of a Dryden Flight Research Center F-18 aircraft, and performed onboard, unattended analysis of 26 engine sensors from engine startup to shutdown. The BEAM algorithm can detect anomalies based solely on the sensor data, which includes but is not limited to sensor failure, performance degradation, incorrect operation such as unplanned engine shutdown or flameout in this example, and major system faults. BEAM was tested on an F-18 simulator, static engine tests, and 25 individual flights totaling approximately 60 hours of flight time. During these tests, BEAM successfully identified planned anomalies (in-flight shutdowns of one engine) as well as minor unplanned anomalies (e.g., transient oil- and fuel-pressure drops), with no false alarms or suspected false-negative results for the period tested. BEAM also detected previously unknown behavior in the F- 18 compressor section during several flights. This result, confirmed by direct analysis of the raw data, serves as a significant test of BEAM's capability.

Mackey, Ryan↗

Flight test of a resident backup software system

A new fault-tolerant system software concept employing the primary digital computers as host for the backup software portion has been implemented and flight tested in the F-8 digital fly-by-wire airplane. The system was implemented in such a way that essentially no transients occurred in transferring from primary to backup software. This was accomplished without a significant increase in the complexity of the backup software. The primary digital system was frame synchronized, which provided several advantages in implementing the resident backup software system. Since the time of the flight tests, two other flight vehicle programs have made a commitment to incorporate resident backup software similar in nature to the system described in this paper.

Deets, D. A.↗

Flight test of a resident backup software system

A new fault-tolerant system software concept employing the primary digital computers as host for the backup software portion has been implemented and flight tested in the F-8 digital fly-by-wire airplane. The system was implemented in such a way that essentially no transients occurred in transferring from primary to backup software. This was accomplished without a significant increase in the complexity of the backup software. The primary digital system was frame synchronized, which provided several advantages in implementing the resident backup software system. Since the time of the flight tests, two other flight vehicle programs have made a commitment to incorporate resident backup software similar in nature to the system described here.

Deets, Dwain A.↗

Automating Test Procedures Using Robot Software

This paper will discuss the project I was assigned during the 2018 Spring semester NIFS internship, what the project does for NASA, and what I contributed to the project. It will begin with a broad analysis of the types of software I worked on and how they were used to complete the project. Then, it will narrow in scope to concentrate on the group and parts of NASA assigned the project. Next, it will pay attention to the project itself and how it worked. After that, it will focus on my direct contributions to the project. Lastly, a few personal experiences I encountered to make my internship relatable. The initial points discussed will be an introduction to the basics of automated testing and the types of software used. Next, I will briefly discuss why these tools were chosen and whether or not they can be improved. Then, a look at where my group fits into the hierarchy of NASA, what the group working on my project did for NASA, and who were the entities working together for this project. Afterwards, a review of my involvement in the program, my development as an individual, and my new skills and abilities. Finally, a sense of involvement with the community through personal development will be demonstrated using unique experiences only available to me through this internship..

SikuliX↗

An evaluation of the documented requirements of the SSP UIL and a review of commercial software packages for the development and testing of UIL prototypes

A review was conducted of software packages currently on the market which might be integrated with the interface language and aid in reaching the objectives of customization, standardization, transparency, reliability, maintainability, language substitutions, expandability, portability, and flexibility. Recommendations are given for best choices in hardware and software acquisition for inhouse testing of these possible integrations. Software acquisition in the line of tools to aid expert-system development and/or novice program development, artificial intelligent voice technology and touch screen or joystick or mouse utilization as well as networking were recommended. Other recommendations concerned using the language Ada for the user interface language shell because of its high level of standardization, structure, and ability to accept and execute programs written in other programming languages, its DOD ownership and control, and keeping the user interface language simple so that multiples of users will find the commercialization of space within their realm of possibility which is, after all, the purpose of the Space Station.

Gill, Esther Naomi↗

Development of Ada language control software for the NASA power management and distribution test bed

The Ada language software developed to control the NASA Lewis Research Center's Power Management and Distribution testbed is described. The testbed is a reduced-scale prototype of the electric power system to be used on space station Freedom. It is designed to develop and test hardware and software for a 20-kHz power distribution system. The distributed, multiprocessor, testbed control system has an easy-to-use operator interface with an understandable English-text format. A simple interface for algorithm writers that uses the same commands as the operator interface is provided, encouraging interactive exploration of the system.

Wright, Ted↗

Space station software reliability analysis based on failures observed during testing at the multisystem integration facility

Quality of software not only is vital to the successful operation of the space station, it is also an important factor in establishing testing requirements, time needed for software verification and integration as well as launching schedules for the space station. Defense of management decisions can be greatly strengthened by combining engineering judgments with statistical analysis. Unlike hardware, software has the characteristics of no wearout and costly redundancies, thus making traditional statistical analysis not suitable in evaluating reliability of software. A statistical model was developed to provide a representation of the number as well as types of failures occur during software testing and verification. From this model, quantitative measure of software reliability based on failure history during testing are derived. Criteria to terminate testing based on reliability objectives and methods to estimate the expected number of fixings required are also presented.

Tamayo, Tak Chai↗