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 505 records · Page 28

Software testability and its application to avionic software

Randomly generated black-box testing is an established yet controversial method of estimating software reliability. Unfortunately, as software applications have required higher reliabilities, practical difficulties with black-box testing have become increasingly problematic. These practical problems are particularly acute in life-critical avionics software, where requirements of 10 exp -7 failures per hour of system reliability can translate into a probability of failure (POF) of perhaps 10 exp -9 or less for each individual execution of the software. This paper describes the application of one type of testability analysis called 'sensitivity analysis' to B-737 avionics software; one application of sensitivity analysis is to quantify whether software testing is capable of detecting faults in a particular program and thus whether we can be confident that a tested program is not hiding faults. We so 80 by finding the testabilities of the individual statements of the program, and then use those statement testabilities to find the testabilities of the functions and modules. For the B-737 system we analyzed, we were able to isolate those functions that are more prone to hide errors during system/reliability testing.

Voas, Jeffrey M.↗

Increasing Cognitive Reserve with Software - Pilot (ICARUS-Pilot)

The ICARUS-Pilot study sought to quantify and assess the potential benefit of using commercial-off-the-shelf (COTS) cognitive training software to improve cognitive performance in an astronaut-like terrestrial population. Five volunteer research subjects were recruited from the JSC employee population to mimic characteristics of the NASA astronaut population (age, education/discipline). Subject cognitive performance was assessed before and after executing eighteen sessions of remote cognitive training using six exercises within an adaptive app-based COTS software package (BrainHQ, Posit Science) on study-provided tablets. Pre- and post-training cognitive performance was measured using internal BrainHQ assessments as well as Cognition Test Battery (CTB), an independent software test developed specifically for NASA and used currently in research studies on astronauts. BrainHQ exercises were posited to map well or partially to several CTB sub-tests. Subjects provided feedback on their study experience formally via survey at the conclusion of testing and informally throughout the study if they encountered issues.

cognitive training↗

X-57 Flight Systems Integration Path

The foundation for a safe and successful flight test of the National Aeronautics and Space Administration (NASA) X-57 Maxwell all-electric experimental airplane, or any X-Plane, is comprehensive system testing on the ground. This test campaign includes verification and validation (V&V) that the integrated system operates as designed and expected, as well as understanding how the system reacts and responds to failures that can occur during flight by performing failure modes and effects testing (FMET). The aircraft should be in the final flight configuration for these test activities because any modifications, even those that appear insignificant, could affect test outcomes. Although the plan was to perform V&V and FMET testing once the airplane was in the flight configuration, due to multiple component redesigns, concurrent software development, and other problems with on-aircraft testing, the X-57 Maxwell never made it into a full-flight configuration. As a result, a build-up approach was followed to test software and hardware as they became ready in order to continue making progress wherever possible. Using this approach revealed problems with the hardware and software faster than waiting for a full-flight configuration, allowing solutions to be found more quickly and in parallel with other project tasks. Other than unloaded motor testing in a lab setting, the only other test setup was on the airplane itself. On-aircraft testing was preferrable in order to test things as close to a flight configuration as possible but was time consuming due to the requirements for testing on the airplane. To overcome some of the on-aircraft barriers, off-aircraft test configurations, such as the Systems Integration Laboratory (SIL) and hardware-in-the-loop (HIL) setups, were used, but each of these setups had limitations to be considered. As a result, solutions found in the SIL or HIL configurations did not always work as expected on the airplane, resulting in an iterative process between on- and off-aircraft testing to find the final solution. Having a dedicated test platform such as an iron bird that closely represents the aircraft - without flight hardware - would have been the most effective off-aircraft test setup, which could have allowed the project to save time and money and potentially reach flight. This paper will highlight the V&V and FMET considerations and testing prerequisites, the build-up approaches to both software and system testing, the benefits and drawbacks to different test configurations, as well as battery testing and operations.

Kassidy M. Mclaughlin↗

X-57 Flight Systems Integration Path

The foundation for a safe and successful flight test of the National Aeronautics and Space Administration (NASA) X-57 Maxwell all-electric experimental airplane, or any X-Plane, is comprehensive system testing on the ground. This test campaign includes verification and validation (V&V) that the integrated system operates as designed and expected, as well as understanding how the system reacts and responds to failures that can occur during flight by performing failure modes and effects testing (FMET). The aircraft should be in the final flight configuration for these test activities because any modifications, even those that appear insignificant, could affect test outcomes. Although the plan was to perform V&V and FMET testing once the airplane was in the flight configuration, due to multiple component redesigns, concurrent software development, and other problems with on-aircraft testing, the X-57 Maxwell never made it into a full-flight configuration. As a result, a build-up approach was followed to test software and hardware as they became ready in order to continue making progress wherever possible. Using this approach revealed problems with the hardware and software faster than waiting for a full-flight configuration, allowing solutions to be found more quickly and in parallel with other project tasks. Other than unloaded motor testing in a lab setting, the only other test setup was on the airplane itself. On-aircraft testing was preferrable in order to test things as close to a flight configuration as possible but was time consuming due to the requirements for testing on the airplane. To overcome some of the on-aircraft barriers, off-aircraft test configurations, such as the Systems Integration Laboratory (SIL) and hardware-in-the-loop (HIL) setups, were used, but each of these setups had limitations to be considered. As a result, solutions found in the SIL or HIL configurations did not always work as expected on the airplane, resulting in an iterative process between on- and off-aircraft testing to find the final solution. Having a dedicated test platform such as an iron bird that closely represents the aircraft - without flight hardware - would have been the most effective off-aircraft test setup, which could have allowed the project to save time and money and potentially reach flight. This paper will highlight the V&V and FMET considerations and testing prerequisites, the build-up approaches to both software and system testing, the benefits and drawbacks to different test configurations, as well as battery testing and operations.

Kassidy McLaughlin↗

Ground Systems Development Environment (GSDE) interface requirements analysis

A set of procedural and functional requirements are presented for the interface between software development environments and software integration and test systems used for space station ground systems software. The requirements focus on the need for centralized configuration management of software as it is transitioned from development to formal, target based testing. This concludes the GSDE Interface Requirements study. A summary is presented of findings concerning the interface itself, possible interface and prototyping directions for further study, and results of the investigation of the Cronus distributed applications environment.

Church, Victor E.↗

Building a Simplistic Automatic Extruder: Instrument Development Opportunities for the Laboratory

This work presents an automatic extruder as a research experience for undergraduate students. The system offers a user-friendly approach to preparing vesicles, such as liposomes or polymersomes, with a defined size and polydispersity properties crucial for research in biology and macromolecules. It comprises two syringe pumps connected by a membrane filter. The setup is controlled by software. Compared to manual extrusion, this automated system provides advantages, such as precisely controlled variables. The project describes a tool to enhance undergraduate learning in science and engineering laboratories. Building an automatic extruder serves as a simplified model of a complex industrial process. It offers a clear advantage: automating a well-understood manual extrusion process. To make this project accessible, it is broken down into three manageable tasks: software development, hardware assembly, and testing procedures. This breakdown describes the software created, the hardware components used, and the testing procedures conducted for this project. All project data, including software code, testing data, and procedures, are freely available online. This allows undergraduate students to not only begin their own projects but also contribute to this educational instrument’s ongoing development.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗

Validation of NSSC-I software for the Hubble Space Telescope

This paper describes the simulation and test methods used to ensure that the NASA Standard Spacecraft Computer, Model 1, (NSSC-I) flight software for the Hubble Space Telescope properly carries out its requirements for control of scientific observations and for monitoring the health and safety of the payload. The hardware and software test environment is discussed. The different kinds of tests (unit, special real time, and stress tests) that are performed before the software is incorporated into the flight system are described, and the kinds of errors that each test category is best suited to find are listed. Finally, the limitations of the tests are discussed, and current plans for enhancing the test environment are outlined.

Foley, Glenn↗

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗

Measuring Software-Execution Time

Test circuit times routines even during multiprogram operation. Circuit generates pulse started by signal at beginning address of program under test and ended by signal at ending address. Pulse duration measured with logic analyzer to determine execution time.

Pinera, C.↗

GPS and Galileo Developments on Board the International Space Station With the Space Communications and Navigation (SCaN) Testbed

The Space Communications and Navigation (SCaN) is a facility developed by NASA and hosted on board the International Space Station (ISS) on an external truss since 2013.It has the objective of testing navigation and communication experimentations with a Software Defined Radio (SDR) approach, which permits software updates for testing new experimentations.NASA has developed the Space Telecommunications Radio System (STRS) architecture standard for SDRs used in space and ground-based platforms to provide commonality among radio developments to provide enhanced capability. The hardware is equipped with both L band front-end radios and the NASA space network communicates with it using S-band, Ku-band and Ka-band links.In May 2016 Qascom started GARISS (GPS and Galileo Receiver for the ISS), an activity of experimentation in collaboration with ESA and NASA that has the objective to develop and validate the acquisition and processing of combined GPS and Galileo signals on board the ISS SCaN testbed. This paper has the objective to present the mission, and provide preliminary details about the challenges in the design, development and verification of the waveform that will be installed on equipment with limited resources. GARISS is also the first attempt to develop a waveform for the ISS as part of an international collaboration between US and Europe. Although the final mission objective is to target dual frequency processing, initial operations will foresee a single frequency processing. Initial results and trade-off between the two options, as well as the final decision will be presented and discussed. The limited resources on board the SCaN with respect to the challenging requirements to acquire and track contemporaneously two satellite navigation systems, with different modulations and data structure, led to the need to assess the possibility of aiding from ground through the S-band. This option would allow assistance to the space receiver in order to provide knowledge of GNSS orbits and reduce the processing on board. Trade off and various options for telemetry and uplink data are presented and discussed. Finally, integration and validation of the waveform are one of the major challenges of GARISS: The Experiment Development System (EDS) and the the Ground Integration Unit (GIU) for VV will be used prior to conducting the experiment on the ISS. The EDS can be used in lab environment and allows prototyping and verification activities with the simulator, but does not include all hardware components. The GIU on the other side is the flight model which replicates the flying equipment, but has limited flexibility for testing.As conclusion, the project is now approaching the Preliminary Design Review (PDR) and indeed only preliminary results are available. This paper is an opportunity to present the GARISS mission as part of an International cooperation between ESA, NASA and Qascom. The preliminary results include GPS and Galileo processing from space signals, the challenges and trade off decisions, the high level STRS architecture and foreseen experimentation campaign. Detailed results from the test campaigns are expected in 2017.

space navigation↗

Developing interpretable models with optimized set reduction for identifying high risk software components

Applying equal testing and verification effort to all parts of a software system is not very efficient, especially when resources are limited and scheduling is tight. Therefore, one needs to be able to differentiate low/high fault frequency components so that testing/verification effort can be concentrated where needed. Such a strategy is expected to detect more faults and thus improve the resulting reliability of the overall system. This paper presents the Optimized Set Reduction approach for constructing such models, intended to fulfill specific software engineering needs. Our approach to classification is to measure the software system and build multivariate stochastic models for predicting high risk system components. We present experimental results obtained by classifying Ada components into two classes: is or is not likely to generate faults during system and acceptance test. Also, we evaluate the accuracy of the model and the insights it provides into the error making process.

Briand, Lionel C.↗

Model-based software process improvement

The activities of a field test site for the Software Engineering Institute's software process definition project are discussed. Products tested included the improvement model itself, descriptive modeling techniques, the CMM level 2 framework document, and the use of process definition guidelines and templates. The software process improvement model represents a five stage cyclic approach for organizational process improvement. The cycles consist of the initiating, diagnosing, establishing, acting, and leveraging phases.

Zettervall, Brenda T.↗

Application of LANDSAT system for improving methodology for inventory and classification of wetlands

The author has identified the following significant results. A newly developed software system for generating statistics on surface water features was tested using LANDSAT data acquired previous to 1975. This software test provided a satisfactory evaluation of the system and also allowed expansion of data base on prairie water features. The software system recognizes water on the basis of a classification algorithm. This classification is accomplished by level thresholding a single near infrared data channel. After each pixel is classified as water or nonwater, the software system then recognizes ponds or lakes as sets of contiguous pixels or as single isolated pixels in the case of very small ponds. Pixels are considered to be contiguous if they are adjacent between successive scan lines. After delineating each water feature, the software system then assigns the feature a position based upon a geographic grid system and calculates the feature's planimetric area, its perimeter, and a parameter known as the shape factor.

Gilmer, D. S.↗

Assessment Environment for Complex Systems Software Guide

This Software Guide (SG) describes the software developed to test the Assessment Environment for Complex Systems (AECS) by the West Virginia High Technology Consortium (WVHTC) Foundation's Mission Systems Group (MSG) for the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD). This software is referred to as the AECS Test Project throughout the remainder of this document. AECS provides a framework for developing, simulating, testing, and analyzing modern avionics systems within an Integrated Modular Avionics (IMA) architecture. The purpose of the AECS Test Project is twofold. First, it provides a means to test the AECS hardware and system developed by MSG. Second, it provides an example project upon which future AECS research may be based. This Software Guide fully describes building, installing, and executing the AECS Test Project as well as its architecture and design. The design of the AECS hardware is described in the AECS Hardware Guide. Instructions on how to configure, build and use the AECS are described in the User's Guide. Sample AECS software, developed by the WVHTC Foundation, is presented in the AECS Software Guide. The AECS Hardware Guide, AECS User's Guide, and AECS Software Guide are authored by MSG. The requirements set forth for AECS are presented in the Statement of Work for the Assessment Environment for Complex Systems authored by NASA Dryden Flight Research Center (DFRC). The intended audience for this document includes software engineers, hardware engineers, project managers, and quality assurance personnel from WVHTC Foundation (the suppliers of the software), NASA (the customer), and future researchers (users of the software). Readers are assumed to have general knowledge in the field of real-time, embedded computer software development.

tests↗

X-57 Cruise Motor GVT Using Fixed-Base Correction Technique

The National Aeronautics and Space Administration (NASA) Armstrong Flight Research Center (AFRC) completed a modal survey of the X-57 Maxwell aircraft cruise motor system to help inform cruise motor redesign efforts. X-57 Maxwell was an electric propulsion demonstrator aircraft developed by NASA to inform airworthiness standards for electrified-aircraft. The cruise motor system modal survey was completed in spring of 2023 utilizing the fixed-base correction (FBC) ground vibration test (GVT) technique developed by ATA Engineering, to decouple the motor modes from the aircraft modes. Previously during the full aircraft GVT, a detailed modal assessment of the cruise motors was not performed. Owing to the X-57 project’s phase in the aircraft development cycle when the motor redesign effort occurred, the cruise motor GVT could only be performed with the cruise motor system installed on the aircraft, with most of its installation hardware (wiring, baffling, sensors, etc.) attached. An impact hammer was used to provide excitation input at various locations within the tight confines of the cruise motor installation. To better support motor redesign efforts, the FBC methodology was utilized to fix, separate and de-couple the cruise motor modes from aircraft modal response. During the GVT, this required additional impact tap tests on candidate fixed-boundary points for each degree of freedom (DOF) to be fixed. Additional triaxial accelerometers installed at the candidate points were used to compute frequency response functions (FRFs) in X, Y, and Z directions to enable those DOFs to be numerically fixed. Test data was acquired using Hottinger Brüel & Kjær’s LAN-XI data acquisition hardware and BK Connect software. FBC post-test processing was performed using the Structural Modification Using Frequency Response Functions (SMURF) technique with ATA Engineering’s Interface between MATLAB, Analysis, Test (IMAT) software. Utilizing the FBC technique relieved test engineers from having to instrument the entire aircraft to identify and separate aircraft response from cruise motor modes of interest. The FBC technique also permitted structural analysis engineers to omit secondary components from their finite element model (FEM) of the cruise motor system. This FBC modal survey was successful, and the first time NASA AFRC utilized the FBC method on an aircraft rather than a test fixture, and also using an impact hammer rather than multiple shakers allowing significant project schedule and cost savings

Modal Survey↗

Experiments in fault tolerant software reliability

Twenty functionally equivalent programs were built and tested in a multiversion software experiment. Following unit testing, all programs were subjected to an extensive system test. In the process sixty-one distinct faults were identified among the versions. Less than 12 percent of the faults exhibited varying degrees of positive correlation. The common-cause (or similar) faults spanned as many as 14 components. However, a majority of these faults were trivial, and easily detected by proper unit and/or system testing. Only two of the seven similar faults were difficult faults, and both were caused by specification ambiguities. One of these faults exhibited variable identical-and-wrong response span, i.e. response span which varied with the testing conditions and input data. Techniques that could have been used to avoid the faults are discussed. For example, it was determined that back-to-back testing of 2-tuples could have been used to eliminate about 90 percent of the faults. In addition, four of the seven similar faults could have been detected by using back-to-back testing of 5-tuples. It is believed that most, if not all, similar faults could have been avoided had the specifications been written using more formal notation, the unit testing phase was subject to more stringent standards and controls, and better tools for measuring the quality and adequacy of the test data (e.g. coverage) were used.

Mcallister, David F.↗

Improving Flight Software Module Validation Efforts : a Modular, Extendable Testbed Software Framework

Ever since Explorer-1, the United States' first Earth satellite, was developed and launched in 1958, JPL has developed many more spacecraft, including landers and orbiters. While these spacecraft vary greatly in their missions, capabilities,and destination, they all have something in common. All of the components of these spacecraft had to be comprehensively tested. While thorough testing is important to mitigate risk, it is also a very expensive and time consuming process. Thankfully,since virtually all of the software testing procedures for SMAP are computer controlled, these procedures can be automated. Most people testing SMAP flight software (FSW) would only need to write tests that exercise specific requirements and then check the filtered results to verify everything occurred as planned. This gives developers the ability to automatically launch tests on the testbed, distill the resulting logs into only the important information, generate validation documentation, and then deliver the documentation to management. With many of the steps in FSW testing automated, developers can use their limited time more effectively and can validate SMAP FSW modules quicker and test them more rigorously. As a result of the various benefits of automating much of the testing process, management is considering this automated tools use in future FSW validation efforts.

flight software testing↗

Wall adjustment strategy software for use with the NASA Langley 0.3-meter transonic cryogenic tunnel adaptive wall test section

The Wall Adjustment Strategy (WAS) software provides successful on-line control of the 2-D flexible walled test section of the Langley 0.3-m Transonic Cryogenic Tunnel. This software package allows the level of operator intervention to be regulated as necessary for research and production type 2-D testing using and Adaptive Wall Test Section (AWTS). The software is designed to accept modification for future requirements, such as 3-D testing, with a minimum of complexity. The WAS software described is an attempt to provide a user friendly package which could be used to control any flexible walled AWTS. Control system constraints influence the details of data transfer, not the data type. Then this entire software package could be used in different control systems, if suitable interface software is available. A complete overview of the software highlights the data flow paths, the modular architecture of the software and the various operating and analysis modes available. A detailed description of the software modules includes listings of the code. A user's manual is provided to explain task generation, operating environment, user options and what to expect at execution.

Wolf, Stephen W. D.↗