Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Verification”

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
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

Computational Analysis of Coupled Geoscience Processes in Fractured and Deformable Media

Prediction of flow, transport, and deformation in fractured and porous media is critical to improving our scientific understanding of coupled thermal-hydrological-mechanical processes related to subsurface energy storage and recovery, nonproliferation, and nuclear waste storage. Especially, earth rock response to changes in pressure and stress has remained a critically challenging task. In this work, we advance computational capabilities for coupled processes in fractured and porous media using Sandia Sierra Multiphysics software through verification and validation problems such as poro-elasticity, elasto-plasticity and thermo-poroelasticity. We apply Sierra software for geologic carbon storage, fluid injection/extraction, and enhanced geothermal systems. We also significantly improve machine learning approaches through latent space and self-supervised learning. Additionally, we develop new experimental technique for evaluating dynamics of compacted soils at an intermediate scale. Overall, this project will enable us to systematically measure and control the earth system response to changes in stress and pressure due to subsurface energy activities.

58 GEOSCIENCES↗
NASA NTRS2011

Seven Processes that Enable NASA Software Engineering Technologies

This slide presentation reviews seven processes that NASA uses to ensure that software is developed, acquired and maintained as specified in the NPR 7150.2A requirement. The requirement is to ensure that all software be appraised for the Capability Maturity Model Integration (CMMI). The enumerated processes are: (7) Product Integration, (6) Configuration Management, (5) Verification, (4) Software Assurance, (3) Measurement and Analysis, (2) Requirements Management and (1) Planning & Monitoring. Each of these is described and the group(s) that are responsible is described.

Housch, Helen↗
NASA NTRS1998

Towards a Theory for Integration of Mathematical Verification and Empirical Testing

From the viewpoint of a project manager responsible for the V&V (verification and validation) of a software system, mathematical verification techniques provide a possibly useful orthogonal dimension to otherwise standard empirical testing. However, the value they add to an empirical testing regime both in terms of coverage and in fault detection has been difficult to quantify. Furthermore, potential cost savings from replacing testing with mathematical verification techniques cannot be realized until the tradeoffs and synergies can be formulated. Integration of formal verification with empirical testing is also difficult because the idealized view of mathematical verification providing a correctness proof with total coverage is unrealistic and does not reflect the limitations imposed by computational complexity of mathematical techniques. This paper first describes a framework based on software reliability and formalized fault models for a theory of software design fault detection - and hence the utility of various tools for debugging. It then describes a utility model for integrating mathematical and empirical techniques with respect to fault detection and coverage analysis. It then considers the optimal combination of black-box testing, white-box (structural) testing, and formal methods in V&V of a software system. Using case studies from NASA software systems, it then demonstrates how this utility model can be used in practice.

Lowry, Michael↗
NASA NTRS2010

The Role and Quality of Software Safety in the NASA Constellation Program

In this study, we examine software safety risk in the early design phase of the NASA Constellation spaceflight program. Obtaining an accurate, program-wide picture of software safety risk is difficult across multiple, independently-developing systems. We leverage one source of safety information, hazard analysis, to provide NASA quality assurance managers with information regarding the ongoing state of software safety across the program. The goal of this research is two-fold: 1) to quantify the relative importance of software with respect to system safety; and 2) to quantify the level of risk presented by software in the hazard analysis. We examined 154 hazard reports created during the preliminary design phase of three major flight hardware systems within the Constellation program. To quantify the importance of software, we collected metrics based on the number of software-related causes and controls of hazardous conditions. To quantify the level of risk presented by software, we created a metric scheme to measure the specificity of these software causes. We found that from 49-70% of hazardous conditions in the three systems could be caused by software or software was involved in the prevention of the hazardous condition. We also found that 12-17% of the 2013 hazard causes involved software, and that 23-29% of all causes had a software control. Furthermore, 10-12% of all controls were software-based. There is potential for inaccuracy in these counts, however, as software causes are not consistently scoped, and the presence of software in a cause or control is not always clear. The application of our software specificity metrics also identified risks in the hazard reporting process. In particular, we found a number of traceability risks in the hazard reports may impede verification of software and system safety.

Layman, Lucas↗
NASA NTRS1989

A general purpose CCD controller

A new type of controller for scientific CCDs that has been designed and tested at NASA-Goddard is described. It features the flexibility of software waveform generation as well as the speed and accuracy of clocking by hardware. The basic CCD operation is described as well as the controller architecture; controller operation; experimental verification; and software, hardware, and data acquisition.

Chen, P. C.↗
NASA NTRS2000

The Impact of Autonomous Systems Technology on JPL Mission Software

This paper discusses the following topics: (1) Autonomy for Future Missions- Mars Outposts, Titan Aerobot, and Europa Cryobot / Hydrobot; (2) Emergence of Autonomy- Remote Agent Architecture, Closing Loops Onboard, and New Millennium Flight Experiment; and (3) Software Engineering Challenges- Influence of Remote Agent, Scalable Autonomy, Autonomy Software Validation, Analytic Verification Technology, and Autonomy and Software Software Engineering.

Doyle, Richard J.↗
NASA NTRS2005

Comparison of Fiber Optic Strain Demodulation Implementations

NASA Langley Research Center is developing instrumentation based upon principles of Optical Frequency-Domain Reflectometry (OFDR) for the provision of large-scale, dense distribution of strain sensors using fiber optics embedded with Bragg gratings. Fiber Optic Bragg Grating technology enables the distribution of thousands of sensors immune to moisture and electromagnetic interference with negligible weight penalty. At Langley, this technology provides a key component for research and development relevant to comprehensive aerospace vehicle structural health monitoring. A prototype system is under development that includes hardware and software necessary for the acquisition of data from an optical network and conversion of the data into strain measurements. This report documents the steps taken to verify the software that implements the algorithm for calculating the fiber strain. Brief descriptions of the strain measurement system and the test article are given. The scope of this report is the verification of software implementations as compared to a reference model. The algorithm will be detailed along with comparison results.

Quach, Cuong C.↗
NASA NTRS1987

Digital-flight-control-system software written in automated-engineering-design language: A user's guide of verification and validation tools

The user guide of verification and validation (V&V) tools for the Automated Engineering Design (AED) language is specifically written to update the information found in several documents pertaining to the automated verification of flight software tools. The intent is to provide, in one document, all the information necessary to adequately prepare a run to use the AED V&V tools. No attempt is made to discuss the FORTRAN V&V tools since they were not updated and are not currently active. Additionally, the current descriptions of the AED V&V tools are contained and provides information to augment the NASA TM 84276. The AED V&V tools are accessed from the digital flight control systems verification laboratory (DFCSVL) via a PDP-11/60 digital computer. The AED V&V tool interface handlers on the PDP-11/60 generate a Univac run stream which is transmitted to the Univac via a Remote Job Entry (RJE) link. Job execution takes place on the Univac 1100 and the job output is transmitted back to the DFCSVL and stored as a PDP-11/60 printfile.

Saito, Jim↗
NASA NTRS2000

Verification and Validation of Autonomy Software at NASA

Autonomous software holds the promise of new operation possibilities, easier design and development and lower operating costs. However, as those system close control loops and arbitrate resources on board with specialized reasoning, the range of possible situations becomes very large and uncontrollable from the outside, making conventional scenario-based testing very inefficient. Analytic verification and validation (V&V) techniques, and model checking in particular, can provide significant help for designing autonomous systems in a more efficient and reliable manner, by providing a better coverage and allowing early error detection. This article discusses the general issue of V&V of autonomy software, with an emphasis towards model-based autonomy, model-checking techniques and concrete experiments at NASA.

Pecheur, Charles↗
NASA NTRS2000

Verification and Validation of Autonomy Software at NASA

Autonomous software holds the promise of new operation possibilities, easier design and development, and lower operating costs. However, as those system close control loops and arbitrate resources on-board with specialized reasoning, the range of possible situations becomes very large and uncontrollable from the outside, making conventional scenario-based testing very inefficient. Analytic verification and validation (V&V) techniques, and model checking in particular, can provide significant help for designing autonomous systems in a more efficient and reliable manner, by providing a better coverage and allowing early error detection. This article discusses the general issue of V&V of autonomy software, with an emphasis towards model-based autonomy, model-checking techniques, and concrete experiments at NASA.

Pecheur, Charles↗
NASA NTRS2004

On-Orbit Software Analysis

The On-Orbit Software Analysis Research Infusion Project was done by Intrinsyx Technologies Corporation (Intrinsyx) at the National Aeronautics and Space Administration (NASA) Ames Research Center (ARC). The Project was a joint collaborative effort between NASA Codes IC and SL, Kestrel Technology (Kestrel), and Intrinsyx. The primary objectives of the Project were: Discovery and verification of software program properties and dependencies, Detection and isolation of software defects across different versions of software, and Compilation of historical data and technical expertise for future applications

Moran, Susanne I.↗
NASA NTRS1989

Initial Ada components evaluation

The SAIC has the responsibility for independent test and validation of the SSE. They have been using a mathematical functions library package implemented in Ada to test the SSE IV and V process. The library package consists of elementary mathematical functions and is both machine and accuracy independent. The SSE Ada components evaluation includes code complexity metrics based on Halstead's software science metrics and McCabe's measure of cyclomatic complexity. Halstead's metrics are based on the number of operators and operands on a logical unit of code and are compiled from the number of distinct operators, distinct operands, and total number of occurrences of operators and operands. These metrics give an indication of the physical size of a program in terms of operators and operands and are used diagnostically to point to potential problems. McCabe's Cyclomatic Complexity Metrics (CCM) are compiled from flow charts transformed to equivalent directed graphs. The CCM is a measure of the total number of linearly independent paths through the code's control structure. These metrics were computed for the Ada mathematical functions library using Software Automated Verification and Validation (SAVVAS), the SSE IV and V tool. A table with selected results was shown, indicating that most of these routines are of good quality. Thresholds for the Halstead measures indicate poor quality if the length metric exceeds 260 or difficulty is greater than 190. The McCabe CCM indicated a high quality of software products.

Moebes, Travis↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRS2018

LADEE Simulation for Mission Operations

The Lunar Atmosphere Dust Environment Explorer (LADEE) model-based spacecraft simulator has been discussed previously at the Workshop on Spacecraft Flight Software including the verification and validation of the flight software, hardware integration of payloads, and multi-domain simulation. In addition to flight software development and testing the LADEE simulator was used by Mission Operations to develop and test spacecraft command scripts, train operators during mission simulations, verification of all tactical command sequence files uploaded to spacecraft during flight.This presentation will discuss the experience of the LADEE operations team using the spacecraft simulator including implementation, processes and lessons learned. We will also discuss a specific instance where the simulator was used in operations to debug and design a software fix for a spacecraft anomaly experienced with the star tracker.

Operations↗