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 649 records · Page 36
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

NASA Operational Simulator for SmallSats (NOS3): Design Reference Mission

The NASA Operational Simulator for Small Satellites (NOS3) has undergone significant advances including updating the framework to be “component” based and expanding the open-source code to include a generic design reference mission to enable advanced technologies. This paper details the changes to the framework as well as a number of innovative use-cases the team is currently supporting such as 1) the expansion of NOS3 to support distributed systems missions in collaboration with NASA GSFC, 2) the integration of NASA JPL’s Science Yield improvement via Onboard Prioritization and Summary of Information Systems (SYNOPSIS) for on-orbit science data prioritization, and 3) the inclusion of NASA IV&V’s software-only CCSDS encryption library (CryptoLib). NOS3 continues to serve the SmallSat community by providing an open-source digital twin that can significantly reduce costs associated with spacecraft software development, test, and operations. The NOS3 team hopes to continue to expand the resources available to the community and partner with others to resolve issues and add new features requested via the NASA GitHub.

SmallSats↗
NASA NTRSDate not supplied

Design Considerations of an Ascent Abort Monitor Algorithm for Use During Service Module Aborts

In support of human rating the Artemis missions, NASA's Orion program requires continuous abort coverage from liftoff through mission destination. During a portion of the ascent trajectory, the currently achievable abort mode is determined by an Orion algorithm using the onboard navigated vehicle state. This ascent abort monitor determines achievability for Orion's Mode 2 abort, Untargeted Abort Splashdown (UAS), by propagating the current vehicle state through ascent abort events to determine sufficient timing to perform the abort and to a ballistic touchdown point to approximate landing location relative to prescribed keep out boundaries. The algorithm was updated for Artemis 2 to allow the capability to limit loads for the majority of ascent. Performance of the algorithm has been demonstrated and verified through dispersed trajectory analysis with emulated flight software, unit testing, and hardware in the loop testing.

Esteban Guzman↗
DOE OSTI2023

Assessment of the Phase-to-Ground Fault Apparent Admittance Method with Phase/Ground Boundaries to Detect Types of Electrical Faults for Protective Relays Using Signature Library and Simulated Events

Protective relays in electric power grids recognize the types of electrical faults in a few seconds. The most common detection method to detect the types of electrical faults is based on measuring the angle between the zero and negative sequence currents. However, it is not completely accurate because the phase to phase ground and phase to ground electrical faults could have the same detection conditions. Therefore, engineers need to plot the events after an electrical fault to observe the nature of the incidents in detail. In this study, the phase to ground fault apparent (PGFA) admittance method with phase/ground boundaries identified the types of electrical faults located in distribution power lines and feeders. This method was based on measuring the PGFA admittance magnitudes for the faulted and non-faulted phases, resulting in greater than zero and near zero, respectively. The PGFA admittance algorithm was built with MATLAB/ Simulink software and tested with signature library and grid simulation events. The PGFA method with phase/ground boundaries was evaluated with the confusion matrix. The measured and predicted values matched in more than 90% of the tests, and the PGFA admittance method with phase/ground boundaries presented an accuracy of 94.3% and a precision of 100%.

Piesciorovsky, Emilio↗
DOE OSTI2013

On the use of genetic algorithm to optimize industrial assets lifecycle management under safety and budget constraints

The purpose of this paper is to describe the method and tool dedicated to optimize investments planning for industrial assets. These investments may either be preventive maintenance tasks, asset enhancements or logistic investments such as spare parts purchases. The two methodological points to investigate in such an issue are: 1. The measure of the profitability of a portfolio of investments 2. The selection and planning of an optimal set of investments 3. The measure of the risk of a portfolio of investments The measure of the profitability of a set of investments in the IPOP tool is synthesised in the Net Present Value indicator. The NPV is the sum of the differences of discounted cash flows (direct costs, forced outages...) between the situations with and without a given investment. These cash flows are calculated through a pseudo-Markov reliability model representing independently the components of the industrial asset and the spare parts inventories. The component model has been widely discussed over the years but the spare part model is a new one based on some approximations that will be discussed. This model, referred as the NPV function, takes for input an investments portfolio and gives its NPV. The second issue is to optimize the NPV. If all investments were independent, this optimization would be an easy calculation, unfortunately there are two sources of dependency. The first one is introduced by the spare part model, as if components are indeed independent in their reliability model, the fact that several components use the same inventory induces a dependency. The second dependency comes from economic, technical or logistic constraints, such as a global maintenance budget limit or a safety requirement limiting the residual risk of failure of a component or group of component, making the aggregation of individual optimum not necessary feasible. The algorithm used to solve such a difficult optimization problem is a genetic algorithm. After a description of the features of the software a test case is presented showing the influence of the optimization algorithm parameters on its efficiency to find an optimal investments planning. (authors)

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2013

Evaluation of vectorized Monte Carlo algorithms on GPUs for a neutron Eigenvalue problem

Conventional Monte Carlo (MC) methods for radiation transport computations are 'history-based', which means that one particle history at a time is tracked. Simulations based on such methods suffer from thread divergence on the graphics processing unit (GPU), which severely affects the performance of GPUs. To circumvent this limitation, event-based vectorized MC algorithms can be utilized. A versatile software test-bed, called ARCHER - Accelerated Radiation-transport Computations in Heterogeneous Environments - was used for this study. ARCHER facilitates the development and testing of a MC code based on the vectorized MC algorithm implemented on GPUs by using NVIDIA's Compute Unified Device Architecture (CUDA). The ARCHER{sub GPU} code was designed to solve a neutron eigenvalue problem and was tested on a NVIDIA Tesla M2090 Fermi card. We found that although the vectorized MC method significantly reduces the occurrence of divergent branching and enhances the warp execution efficiency, the overall simulation speed is ten times slower than the conventional history-based MC method on GPUs. By analyzing detailed GPU profiling information from ARCHER, we discovered that the main reason was the large amount of global memory transactions, causing severe memory access latency. Several possible solutions to alleviate the memory latency issue are discussed. (authors)

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Improving and Automating Building Model Data Exchange

There are many instances throughout a project’s lifecycle where there arises a need for quick and accurate risk assessment of building designs. For example, an unexpected design change during construction may necessitate structural engineers to perform a seismic risk assessment on analytical models of the updated building design using high fidelity structural analysis software, such as ANSYS or Abaqus. However, the efficiency of such workflows often depends upon the interoperability of architectural design software and structural analysis software. When the quality of this interoperability is lacking or even non-existent, the efficiency of virtual engineering workflows is hampered, which increases project costs. A McGraw Hill industry survey of professional users of Building Information Modeling (BIM) technologies found that there is high demand for BIM interoperability for structural analysis, but that the value/difficulty ratio is currently too low for practical use. There have been efforts by the academic community to facilitate model data exchange between the architectural design and structural analysis domains, but such solutions have not been widely adopted by industry, face technical challenges, and oftentimes are limited in applicability for users of various BIM software. Therefore, INL is developing capabilities to improve, automate, and generalize model data exchange between architectural BIM software (e.g., Revit) and structural analysis software (e.g., SAP2000, ANSYS). The goal is to help expedite and automate as much of the pre-processing step for creating analytical models in finite element analysis software as reasonably as possible. Such a "BIM-to-FEA" conversion tool should provide direct benefit to end-users through accuracy, automation, quick turn-around, and wide applicability. To generalize the application of this BIM-to-FEA conversion tool and increase its useability among the many different commercial BIM software currently used by industry, the program is being developed with the concept of openBIM. OpenBIM is the application of non-proprietary, open data standards that allow for BIM model data exchange in a format that is accessible, retainable, and useable for all users. The most widely used open, non-proprietary data exchange format for BIM is the Industry Foundation Classes (IFC) schema. IFC is developed by buildingSMART international and is ISO certified (ISO 16739-1:2018). The BIM-to-FEA conversion tool is being developed for compatibility with typical commercial building designs of steel framed structures. The tool is currently capable of importing architectural BIM data of framed building structures, recognizing and extracting the aspects of the model that are required for structural analysis, adjusting the connectivity of frame members, and finally exporting to an analytical model stored in the IFC format. The exported IFC analytical model can then be imported into various openBIM compliant software, such as SAP2000. Such capabilities have already been tested on commercial software, as shown above, and continue to be improved. Work is underway to test the conversion on various commercial BIM software, develop a user-friendly interface, incorporate the program into the broader DeepLynx data warehouse project being developed by INL, and to eventually open-source the tool for the benefit of the community. Future development of the tool envisions the ability for efficient iterative risk assessment of generative building designs, all within a workflow utilizing open-source tools. One such open-source tool will be MOOSE, an advanced finite element analysis tool developed at INL. The conversion tool will also branch out from typical commercial building designs and will aim to incorporate nuclear construction. The aim will be to convert both structural and non-structural components of nuclear facilities, such as curved concrete containment structures and piping systems, respectively.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1998

Testing and Troubleshooting Automatically Generated Source Code

Tools allowing engineers to model the real-time behavior of systems that control many types of NASA systems have become widespread. These tools automatically generate source code that is compiled, linked, then downloaded into computers controlling everything from wind tunnels to space flight systems. These tools save hundreds of hours of software development time and allow engineers with thorough application area knowledge but little software development experience to generate software to control the systems they use daily. These systems are verified and validated by simulating the real-time models, and by other techniques that focus on the model or the hardware. The automatically generated source code is typically not subjected to rigorous testing using conventional software testing techniques. Given the criticality and safety issues surrounding these systems, the application of conventional and new software testing and troubleshooting techniques to the automatically generated will improve the reliability of the resulting systems.

Henry, Joel↗
NASA NTRS1993

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.↗
DOE OSTI2016

Finite-Test-Case Development to Demonstrate Logical Integrity of Software in DRPS

Reactor protection system (RPS) in nuclear power plant (NPP) is in the process of digitalization in response to advanced features of digital systems. In this context, software integrity in the RPS becomes an important issue since it may cause common-cause failure. Therefore, to guarantee the safety of NPPs, the integrity of the software need to be properly demonstrated or assessed. There are three typical approaches for software reliability quantification: software reliability growth model (SRGM), Bayesian belief network (BBN), and test-based method. Basically, SRGM is difficult to apply to the safety-critical software because not only sufficient failure sets are unavailable but consequence of system failure is also unacceptable. Then the result obtained through the BBN model may have large uncertainty, so it produces difficulties in integrity demonstration of safety-critical software. Thus, the BBN result need to be complemented or verified by test-based method. Currently, for the integrity demonstration of safety-critical software, black-box test which feeds inputs and examines just outputs whether they succeeded or failed is considered based on trajectory-form-of-input (a series of successive values for the input variables that occur during the operation of the software over time). Usually these trajectory-inputs are randomly sampled from operational profile. In this approach, however, there are some practical difficulties. Therefore, we proposed a new test method for safety-critical software in digitalized reactor protection system (DRPS). The main contents described in this paper are about basic concepts under development of finite-test-cases by which the integrity of the software logic can be verified. It should be noted that the influence of the environments, such as operating system and other hardware, are not considered since the method focuses on software logic only. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2015

SU-E-T-76: A Software System to Monitor VMAT Plan Complexity in a Large Radiotherapy Centre

Purpose: To develop a system that analyses and reports the complexity of Volumetric Modulated Arc Therapy (VMAT) plans to aid in the decision making for streamlining patient specific dosimetric quality assurance (QA) tests. Methods: A software system, Delcheck, was developed in-house to calculate VMAT plan and delivery complexity using the treatment delivery file. Delcheck has the functionality to calculate multiple plan complexity metrics including the Li-Xing Modulation Index (LI-MI), multiplicative combination of Leaf Travel and Modulation Complexity Score (LTMCSv), Monitor Units per prescribed dose (MU/D) and the delivery complexity index (MIt) that incorporates the modulation of dose rate, leaf speed and gantry speed. Delcheck includes database functionality to store and compare plan metrics for a specified treatment site. The overall plan and delivery complexity is assessed based on the 95% conformance limit of the complexity metrics as Similar, More or Less complex. The functionality of the software was tested using 42 prostate conventional, 10 prostate SBRT and 15 prostate bed VMAT plans generated for an Elekta linear accelerator. Results: The mean(σ) of LI-MI for conventional, SBRT and prostate bed plans were 1690(486), 3215.4(1294) and 3258(982) respectively. The LTMCSv of the studied categories were 0.334(0.05), 0.325(0.07) and 0.3112(0.09). The MU/D of the studied categories were 2.4(0.4), 2.7(0.7) and 2.5(0.5). The MIt of the studied categories were 21.6(3.4), 18.2(3.0) and 35.9(6.6). The values of the complexity metrics show that LI-MI appeared to resolve the plan complexity better than LTMCSv and MU/D. The MIt value increased as the delivery complexity increased. Conclusion: The developed software was shown to be working as expected. In studied treatment categories Prostate bed plans are more complex in both plan and delivery and SBRT is more complex in plan and less complex in delivery as demonstrated by LI-MI and MIt. This project was funded through a Cancer Council NSW Project Grant (RG14-11)

60 APPLIED LIFE SCIENCES↗
NASA NTRS2022

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↗
NASA NTRSDate not supplied

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↗
NASA NTRSDate not supplied

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↗
DOE OSTI2022

Enabling Autonomous Electron Microscopy for Networked Computation and Steering

Advanced electron microscopy workflows require an ecosystem of microscope instruments and computing systems possibly located at different sites to conduct remotely steered and automated experiments. Current workflow executions involve manual operations for steering and measurement tasks, which are typically performed from control workstations co-located with microscopes; consequently, their operational tempo and effectiveness are limited. We propose an approach based on separate data and control channels for such an ecosystem of Scanning Transmission Electron Microscopes (STEM) and computing systems, for which no general solutions presently exist, unlike the neutron and light source instruments. We demonstrate automated measurement transfers and remote steering of Nion STEM physical instruments over site networks. We propose a Virtual Infrastructure Twin (VIT) of this ecosystem, which is used to develop and test our steering software modules without requiring access to the physical instrument infrastructure. Additionally, we develop a VIT for a multiple laboratory scenario, which illustrates the applicability of this approach to ecosystems connected over wide-area networks, for the development and testing of software modules and their later field deployment.

Al Najjar, Anees↗