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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,477 records · Page 82

All sources NASA NTRS DOE OSTI

NASA NTRS2006

A Case for Developing a Ground Based Replication of the Earth, Moon and Mars Spaceflight Infrastructure

When the systems are developed and in place to provide the services needed to operate en route and on the Lunar and Martian surfaces, an Earth based replication will need to be in place for the safety and protection of mission success. The replication will entail all aspects of the flight configuration end to end but will not include any closed loop systems. This would replicate the infrastructure from Lunar and Martian robots, manned surface excursions, through man and unmanned terrestrial bases, through the various types of communication systems and technologies, manned and un-manned space vehicles (large and small), to Earth based systems and control centers. An Earth based replicated infrastructure will enable checkout and test of new technologies, hardware, software updates and upgrades and procedures without putting humans and missions at risk. Analysis of events, what ifs and trouble resolution could be played out on the ground to remove as much risk as possible from any type of proposed change to flight operational systems. With adequate detail, it is possible that failures could be predicted with a high probability and action taken to eliminate failures. A major factor in any mission to the Moon and to Mars is the complexity of systems, interfaces, processes, their limitations, associated risks and the factor of the unknown including the development by many contractors and NASA centers. The need to be able to introduce new technologies over the life of the program requires an end to end test bed to analyze and evaluate these technologies and what will happen when they are introduced into the flight system. The ability to analyze system behaviors end to end under varying conditions would enhance safety e.g. fault tolerances. This analysis along with the ability to mine data from the development environment (e.g. test data), flight ops and modeling/simulations data would provide a level of information not currently available to operations and astronauts. In this paper we will analyze the beginnings of such a replication and what it could do in terms of reducing risk in the near term for development. We will analyze the Space Shuttle Main Engine (SSME) test lab which has to a large extent accomplished this replication for the SSME and has been highly successful in analyzing hardware and software problems and changes. The cost of replicating the flight system as proposed here could be very high if attempted as an afterthought. We will describe the initial steps for the development of a replication of this infrastructure starting with the communication infrastructure. The Constellation of Labs (CofL) under the Command, Control, Communication and Information (C3I) project for the NASA Exploration Initiative will provide the initial foundation upon which to base this replication. Simply put, there is very little margin for error in high latency situations e.g. en-route to/from Mars or in an autonomous process on the Lunar far side. Any thought out approach to reduce risk and increase safety needs to be accomplished end to end with the actual systems configuration.

Bradford, Robert N.↗

NASA NTRS2021

Integration of an Arm Kinematics Hot Patch onboard the Curiosity Rover

NASA's Mars Science Laboratory (MSL) mission has updated the Curiosity rover's flight software multiple times since landing on Mars on August 6, 2012. The most common patching method has been a hot patch, in which running flight software is modified after being copied into RAM from its persistent storage. The latest hot patch to be installed on Curiosity fixed an issue in the robotic arm software that computes generalized inverse kinematics. Additional unit testing performed since the start of the surface mission revealed that this software can sometimes produce erroneous solutions.The cause was identified as numerical instability in a quartic root finder. When the inputs to that solver are not well conditioned, floating-point numerical issuescan cause erroneous roots to be reported. In theory, this could result in the robotic arm turret instruments being commanded to unintended positions, for example, below the terrain surface. Out of approximately 3.7 million unit test cases, 97.2\% of the position errors were below 5 mm. However, there were 16 test cases where theposition error was greater than 20 cm, and the maximum position error was 1.2 meters.The patch was uploaded to Curiosity on sol 2642 (January 11, 2020) after the solution was developed, re-implemented as a hot patch, and validated and verified using Earth-based Curiosity testbeds. A checkout test of the patch was performed on Curiosity on sol 2657, and nominal use of the patch began on sol 2658. In this paper, we describe the steps that led to integrating the arm kinematic hot patch into Curiosity's flight software, from the discovery of the bug to the nominal use of the patch in flight.

Maimone, Mark↗

DOE OSTI2025

MaPSA Quality Control and AI-Enhanced Grading For the CMS Phase-II Tracker Upgrade

The Compact Muon Solenoid (CMS) experiment will undergo changes as part of the Large Hadron Collider upgrade. The CMS tracker will be upgraded to cope with the new radiation environment and to provide tracking at the first level trigger. This upgrade features a new type of silicon module called PS Module, which combines a Pixel sensor and a Strip sensor in the same module. The pixel portion of the PS module has a sensor bump bonded to 16 Macro Pixel ASICs (MPA) to form a Macro Pixel Sub Assembly (MaPSA). At Fermilab, MaPSAs are tested for quality control before being assembled with the strip sensors, readout and service electronics to form a PS Module. All of this test data is stored in a centralized database, and is used to grade the final module to determine if it will be installed in the detector. The Phase II Outer Tracker Analyzer of Test Outputs (POTATO) is the software that processes this data and determines the module grades. Using recent technologies, an AI agent is being im plemented into POTATO in order to allow users to more efficiently sort through the large amounts of analysis data and ensure that only the user specified data is being considered. This poster will display the process of testing a MaPSA, how that test data is relevant to module assembly and grading, and how the POTATO grading tool is being improved with the use of an embedded AI agent.

Gzamouranis, Olivia [Purdue U.]↗

NASA NTRS2000

PTS performance by flight- and control-group macaques

A total of 25 young monkeys (Macaca mulatta) were trained with the Psychomotor Test System, a package of software tasks and computer hardware developed for spaceflight research with nonhuman primates. Two flight monkeys and two control monkeys were selected from this pool and performed a psychomotor task before and after the Bion 11 flight or a ground-control period. Monkeys from both groups showed significant disruption in performance after the 14-day flight or simulation (plus one anesthetized day of biopsies and other tests), and this disruption appeared to be magnified for the flight animal.

Flight Experiment↗

DOE OSTI2023

Modeling the U.S. Western Electric Interconnection to Understand the Consequences of Hydrometeorological Extremes and Options for Risk Mitigation

Electricity grid operators around the world face a dual challenge; withstanding increasingly severe weather and the longer term impacts of climate change, while simultaneously decarbonizing. Extreme weather events such as heat waves and droughts are rising in both severity and frequency, which is threatening the reliability of electricity grids through increased demand, generation capacity losses, and equipment failures. Consequently, incorporating hydrometeorological stressors into computational power systems analysis is becoming an even more critical tool in long term planning and short term operations. However, there is a general lack of open-source customizable grid simulation software capable of exhaustively stress testing the grid under hydrometeorological uncertainty, and/or examining potential risk mitigation pathways. A related, persistent challenge for power system modelers is striking an appropriate balance between model fidelity (e.g. spatial scale and time resolution) and computational tractability (wall clock run-time). In this study, we are proposing a solution to this problem with open-source software that allows users to seamlessly customize the scale and track the accuracy of grid operations models. Our approach allows users to search over numerous model parameters (network topology, mathematical formulation, economic hurdle rates, and transmission line scaling) to identify model instantiations that accommodate experimental design. Further, we use this approach to demonstrate the importance of including extreme weather events in model validation and model selection. Focusing on the occurrence of heatwaves and droughts in the U.S. Western Interconnection, we examine role of extreme events in balancing tradeoffs between model fidelity and run-time at the model design stage.

Economics↗

NASA NTRS2008

Random Testing and Model Checking: Building a Common Framework for Nondeterministic Exploration

Two popular forms of dynamic analysis, random testing and explicit-state software model checking, are perhaps best viewed as search strategies for exploring the state spaces introduced by nondeterminism in program inputs. We present an approach that enables this nondeterminism to be expressed in the SPIN model checker's PROMELA language, and then lets users generate either model checkers or random testers from a single harness for a tested C program. Our approach makes it easy to compare model checking and random testing for models with precisely the same input ranges and probabilities and allows us to mix random testing with model checking's exhaustive exploration of non-determinism. The PROMELA language, as intended in its design, serves as a convenient notation for expressing nondeterminism and mixing random choices with nondeterministic choices. We present and discuss a comparison of random testing and model checking. The results derive from using our framework to test a C program with an effectively infinite state space, a module in JPL's next Mars rover mission. More generally, we show how the ability of the SPIN model checker to call C code can be used to extend SPIN's features, and hope to inspire others to use the same methods to implement dynamic analyses that can make use of efficient state storage, matching, and backtracking.

dynamic analysis↗

NASA NTRS1993

Software reliability through fault-avoidance and fault-tolerance

Strategies and tools for the testing, risk assessment and risk control of dependable software-based systems were developed. Part of this project consists of studies to enable the transfer of technology to industry, for example the risk management techniques for safety-concious systems. Theoretical investigations of Boolean and Relational Operator (BRO) testing strategy were conducted for condition-based testing. The Basic Graph Generation and Analysis tool (BGG) was extended to fully incorporate several variants of the BRO metric. Single- and multi-phase risk, coverage and time-based models are being developed to provide additional theoretical and empirical basis for estimation of the reliability and availability of large, highly dependable software. A model for software process and risk management was developed. The use of cause-effect graphing for software specification and validation was investigated. Lastly, advanced software fault-tolerance models were studied to provide alternatives and improvements in situations where simple software fault-tolerance strategies break down.

Vouk, Mladen A.↗

NASA NTRS1986

A study of the use of abstract types for the representation of engineering units in integration and test applications

Physical quantities using various units of measurement can be well represented in Ada by the use of abstract types. Computation involving these quantities (electric potential, mass, volume) can also automatically invoke the computation and checking of some of the implicitly associable attributes of measurements. Quantities can be held internally in SI units, transparently to the user, with automatic conversion. Through dimensional analysis, the type of the derived quantity resulting from a computation is known, thereby allowing dynamic checks of the equations used. The impact of the possible implementation of these techniques in integration and test applications is discussed. The overhead of computing and transporting measurement attributes is weighed against the advantages gained by their use. The construction of a run time interpreter using physical quantities in equations can be aided by the dynamic equation checks provided by dimensional analysis. The effects of high levels of abstraction on the generation and maintenance of software used in integration and test applications are also discussed.

Johnson, Charles S.↗

DOE OSTI2013

DEVELOPING THE NATIONAL GEOTHERMAL DATA SYSTEM ADOPTION OF CKAN FOR DOMESTIC & INTERNATIONAL DATA DEPLOYMENT

The National Geothermal Data System (NGDS) De- sign and Testing Team is developing NGDS software currently referred to as the “NGDS Node-In-A-Box”. The software targets organizations or individuals who wish to host at least one of the following: • an online repository containing resources for the NGDS; • an online site for creating metadata to register re- sources with the NGDS • NDGS-conformant Web APIs that enable access to NGDS data (e.g., WMS, WFS, WCS); • NDGS-conformant Web APIs that support dis- covery of NGDS resources via catalog service (e.g. CSW) • a web site that supports discovery and under- standing of NGDS resources A number of different frameworks for development of this online application were reviewed. The NGDS Design and Testing Team determined to use CKAN (http://ckan.org/), because it provides the closest match between out of the box functionality and NGDS node-in-a-box requirements. To achieve the NGDS vision and goals, this software development project has been inititated to provide NGDS data consumers with a highly functional inter- face to access the system, and to ease the burden on data providers who wish to publish data in the sys- tem. It is important to note that this software package constitutes a reference implementation. The NGDS software is based on open standards, which means other server software can make resources available, and other client applications can utilize NGDS data. A number of international organizations have ex- pressed interest in the NGDS approach to data access. The CKAN node implementation can provide a sim- ple path for deploying this technology in other set- tings.

15 GEOTHERMAL ENERGY↗

DOE OSTI2023

Verification of Spent Fuel Inside Dry Storage Casks by Cask Top Fast Neutron Mapping (FY2023 Mid-Year Report)

This project is developing a prototype scanner array verification system for detection of missing fuel assemblies in spent-fuel storage casks. The prototype consists of six fast-neutron scintillator detectors mounted to a linear actuator frame that is placed on the top of a spent fuel cask to scan across all fuel assembly positions. The scanner array was assembled and tested at LLNL in FY2022. A field test schedule has been requested at the Idaho National Laboratory (INL) Cask Farm site for FY2023. Note that the Cask Farm contractor determines this scheduling and not INL directly. Further system automation will be designed and implemented with the goal of obtaining a level of system operation that meets IAEA needs. This includes integration of the scanner array and data-acquisition control software into a single interface for operator use. In addition, commercial operators and the IAEA may have special requirements for portability, shipping, lifting, and installation. Prior to the Field Test at INL, the system will be operated at LLNL to exercise lifting procedure and linear actuators, monitor stability of detector energy and pulse-shape discrimination calibration, and test system software integration efforts. Following the Field Test, we will present results and discuss the technology with the IAEA. We will incorporate additional improvements to the system based on lessons learned from the field test and feedback from the IAEA. If successful, the technology can be transferred to the IAEA or other stakeholders for assessment.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

DOE OSTI2017

Impact of detector simulation in particle physics collider experiments

Through the last three decades, precise simulation of the interactions of particles with matter and modeling of detector geometries has proven to be of critical importance to the success of the international high-energy physics experimental programs. For example, the detailed detector modeling and accurate physics of the Geant4-based simulation software of the CMS and ATLAS particle physics experiments at the European Center of Nuclear Research (CERN) Large Hadron Collider (LHC) was a determinant factor for these collaborations to deliver physics results of outstanding quality faster than any hadron collider experiment ever before. This review article highlights the impact of detector simulation on particle physics collider experiments. It presents numerous examples of the use of simulation, from detector design and optimization, through software and computing development and testing, to cases where the use of simulation samples made a difference in the accuracy of the physics results and publication turnaround, from data-taking to submission. It also presents the economic impact and cost of simulation in the CMS experiment. Future experiments will collect orders of magnitude more data, taxing heavily the performance of simulation and reconstruction software for increasingly complex detectors. Consequently, it becomes urgent to find solutions to speed up simulation software in order to cope with the increased demand in a time of flat budgets. The study ends with a short discussion on the potential solutions that are being explored, by leveraging core count growth in multicore machines, using new generation coprocessors, and re-engineering of HEP code for concurrency and parallel computing.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

NASA NTRS1987

Summary of paper: Area navigation implementation for a microcomputer-based Loran-C receiver

The development of an area navigation program and the implementation of this software on a microcomputer-based Loran-C receiver to provide high-quality, practical area navigation information for general aviation are described. This software provides range and bearing angle to a selected waypoint, cross-track error, course deviation indication (CDI), ground speed, and estimated time of arrival at the waypoint. The range/bearing calculation, using an elliptical Earth model, provides very good accuracy; the error does not exceed more than -.012 nm (range) or 0.09 degree (bearing) for a maximum range to 530 nm. The alpha-beta filtering is applied in order to reduce the random noise on Loran-C raw data and in the ground speed calculation. Due to alpha-beta filtering, the ground speed calculation has good stability for constant or low-accelerative flight. The execution time of this software is approximately 0.2 second. Flight testing was done with a prototype Loran-C front-end receiver, with the Loran-C area navigation software demonstrating the ability to provide navigation for the pilot to any point in the Loran-C coverage area in true area navigation fashion without line-of-sight and range restriction typical of VOR area navigation.

Oguri, Fujiko↗

NASA NTRS1987

TAVERNS and the space station software support environment

The Space Station Information System (SSIS) provides the data processing capability for the Space Station Program (SSP). The Software Support Environment (SSE) System for the SSP is the collection of software, procedures, standards, hardware specification, documentation, policy, and training materials. The Ada programming language was baselined by the Space Station Program Office as the language for development and maintenance of all space station software including the software of the SSE itself. The Test And Validation Environment for Remote Networked Systems (TAVERNS) is a distributed philosophy for development and validation of Ada applications software for the space station and as such is closely related to the SSE. An overview of the system is provided.

Howes, Norman R.↗

NASA NTRS2005

Apex Reference Manual 3.0 Beta

Apex is a toolkit for constructing software that behaves intelligently and responsively in demanding task environments. Reflecting its origin at NASA where Apex continues to be developed, current applications include: a) Providing autonomous mission management and tactical control capabilities for unmanned aerial vehicles including an autonomous surveillance helicopter and a simulation prototype of an unmanned fixed-wing aircraft to be used for wildfire mapping; b) Simulating human air traffic controllers, pilots and astronauts to help predict how people might respond to changes in equipment or procedures; and c) Predicting the precise duration and sequence of routine human behaviors based on a human-computer interaction engineering technique called CPM-GOMS. Among Apex s components are a set of implemented reasoning services, such as those for reactive planning and temporal pattern recognition; a software architecture that embeds and integrates these services and allows additional reasoning elements to be added as extensions; a formal language for specifying agent knowledge; a simulation environment to facilitate prototyping and analysis; and Sherpa, a set of tools for visualizing autonomy logic and runtime behavior. In combination, these are meant to provide a flexible and usable framework for creating, testing, and deploying intelligent agent software. Overall, our goal in developing Apex is to lower economic barriers to developing intelligent software agents. New ideas about how to extend or modify the system are evaluated in terms of their impact in reducing the time, expertise, and inventiveness required to build and maintain applications. For example, potential enhancements to the AI reasoning capabilities in the system are reviewed not only for usefulness and distinctiveness, but also for their impact on the readability and general usability of Apex s behavior representation language (PDL) and on the transparency of resulting behavior. A second central part of our approach is to iteratively refine Apex based on lessons learned from as diverse a set of applications as possible. Many applications have been developed by users outside the core development team including engineers, researchers, and students. Usability is thus a central concern for every aspect of Apex visible to a user, including PDL, Sherpa, the Apex installation process, APIs, and user documentation. Apex users vary in their areas of expertise and in their familiarity with autonomy technology. Focusing on usability, a development philosophy summarized by the project motto "Usable Autonomy," has been important part of enabling diverse users to employ Apex successfully and to provide feedback needed to guide iterative, user-centered refinement.

Freed, Michael A.↗

NASA NTRS2009

Real-Time Assessment of Robot Performance During Remote Exploration Operations

To ensure that robots are used effectively for exploration missions, it is important to assess their performance during operations. We are investigating the definition and computation of performance metrics for assessing remote robotic operations in real-time. Our approach is to monitor data streams from robots, compute performance metrics, and provide Web-based displays of these metrics for assessing robot performance during operations. We evaluated our approach for measuring robot performance with the K10 rovers from NASA Ames Research Center during a field test at Moses Lake Sand Dunes (WA) in June 2008. In this paper we present the results of evaluating our software for robot performance and discuss our conclusions from this evaluation for future robot operations.

SBIR TOPIC X7.02 PHASE 1↗

DOE OSTI2017

A Collimated CZT Detector for Quantitative Gamma Assays - 17250

Cadmium-Zinc-Telluride [CZT] detectors for gamma spectroscopic measurements and room-temperature operation have had a long history of promising good performance. Very small detectors [0.05-0.5 cm{sup 3}] have been commercially available for many years, but their small size creates problems for spectroscopy because of very low photopeak efficiency, especially at medium and high energies. Large CZT [4-6 cm{sup 3}] detectors have been shown to work nicely in a research environment when complicated electronic and data processing algorithms are applied. We report here test results from a commercially available 1 cubic centimeter CZT detector housed in a portable custom Tungsten shield with a set of collimators with different apertures. The detector has 2-2.5% FWHM resolution at Cs-137 energies, and near-Gaussian shaped peaks. Efficiency calibrations can be quickly made for a wide variety of geometries using the ISOCS mathematical efficiency software. We show successful validation tests comparing accuracy of measurements on reference calibration point sources, line sources, and 200 liter drums. The low weight of the device [9 kg including the shield and collimator] and low power [powered via USB from the PC] makes these devices particularly suitable for human-deployed in-situ measurements of large objects containing medium levels of activity - e.g. characterization of objects encountered during decommissioning, emergency response, truck alarm investigation, or waste being shipped to a disposal facility. (authors)

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

NASA NTRS2006

Grayscale Optical Correlator Workbench

Grayscale Optical Correlator Workbench (GOCWB) is a computer program for use in automatic target recognition (ATR). GOCWB performs ATR with an accurate simulation of a hardware grayscale optical correlator (GOC). This simulation is performed to test filters that are created in GOCWB. Thus, GOCWB can be used as a stand-alone ATR software tool or in combination with GOC hardware for building (target training), testing, and optimization of filters. The software is divided into three main parts, denoted filter, testing, and training. The training part is used for assembling training images as input to a filter. The filter part is used for combining training images into a filter and optimizing that filter. The testing part is used for testing new filters and for general simulation of GOC output. The current version of GOCWB relies on the mathematical software tools from MATLAB binaries for performing matrix operations and fast Fourier transforms. Optimization of filters is based on an algorithm, known as OT-MACH, in which variables specified by the user are parameterized and the best filter is selected on the basis of an average result for correct identification of targets in multiple test images.

Hanan, Jay↗

NASA NTRS2007

The Dangers of Failure Masking in Fault-Tolerant Software: Aspects of a Recent In-Flight Upset Event

On 1 August 2005, a Boeing Company 777-200 aircraft, operating on an international passenger flight from Australia to Malaysia, was involved in a significant upset event while flying on autopilot. The Australian Transport Safety Bureau's investigation into the event discovered that an anomaly existed in the component software hierarchy that allowed inputs from a known faulty accelerometer to be processed by the air data inertial reference unit (ADIRU) and used by the primary flight computer, autopilot and other aircraft systems. This anomaly had existed in original ADIRU software, and had not been detected in the testing and certification process for the unit. This paper describes the software aspects of the incident in detail, and suggests possible implications concerning complex, safety-critical, fault-tolerant software.

Johnson, C. W.↗