Cassini attitude control software testing: performance verification of a deep space mission
Explore the source record for details and available documents.
SEARCH · Engineering Papers
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.
Explore the source record for details and available documents.
Symbolic execution is a well-known program analysis technique which represents values of program inputs with symbolic values instead of concrete (initialized) data and executes the program by manipulating program expressions involving the symbolic values. Symbolic execution has been proposed over three decades ago but recently it has found renewed interest in the research community, due in part to the progress in decision procedures, availability of powerful computers and new algorithmic developments. We provide a survey of some of the new research trends in symbolic execution, with particular emphasis on applications to test generation and program analysis. We first describe an approach that handles complex programming constructs such as input data structures, arrays, as well as multi-threading. We follow with a discussion of abstraction techniques that can be used to limit the (possibly infinite) number of symbolic configurations that need to be analyzed for the symbolic execution of looping programs. Furthermore, we describe recent hybrid techniques that combine concrete and symbolic execution to overcome some of the inherent limitations of symbolic execution, such as handling native code or availability of decision procedures for the application domain. Finally, we give a short survey of interesting new applications, such as predictive testing, invariant inference, program repair, analysis of parallel numerical programs and differential symbolic execution.
Explore the source record for details and available documents.
Over the past two decades, the emergence of highly effective software testing frameworks has greatly simplified the development and use of unit tests and has led to new software development paradigms such as test driven development (TDD). However, scientific computing introduces a number of unique testing challenges, including numerical algorithms, distributed parallelism, and exascale environments. This presentation will begin with a brief introduction to unit testing, testing frameworks, and some simple examples using pFUnit, a unit testing framework for Fortran + MPI. I will then take a closer look at several of the obstacles one faces when testing technical software and suggest methodologies that can mitigate these difficulties.
Over the past two decades, the emergence of highly effective software testing frameworks has greatly simplified the development and use of unit tests and has led to new software development paradigms such as test driven development (TDD). However, technical computing introduces a number of unique testing challenges, including distributed parallelism and numerical accuracy. This webinar will begin with a basic introduction to the use of pFUnit (parallel Fortran Unit testing framework) to develop tests for Message Passing Interface (MPI) plus Fortran (MPI+Fortran) software and then present some of the new capabilities in the latest release. We will also discuss some specialized methodologies for testing numerical algorithms and speculate about future framework capabilities that may improve our ability to test at exascale.
Progress on the development of modeling software, testing software against caclulated data from program VPAP and measured patterns, and calculating roll plane patterns for general aviation aircraft is reported. Major objectives are the continued development of computer software for aircraft modeling and use of this software and program OSUVOL to calculate principal plane and volumetric radiation patterns. The determination of proper placement of antennas on aircraft to meet the requirements of the Microwave Landing System is discussed. An overview of the performed work, and an example of a roll plane model for the Piper PA-31T Cheyenne aircraft and the resulting calculated roll plane radiation pattern are included.
A method of automated testing of software has been developed that provides an alternative to the conventional mostly manual approach for software testing. The method combines (1) automated generation of test cases on the basis of systematic exploration of the input domain of the software to be tested with (2) run-time analysis in which execution traces are monitored, verified against temporal-logic specifications, and analyzed by concurrency-error-detection algorithms. In this new method, the user only needs to provide the temporal logic specifications against which the software will be tested and the abstract description of the input domain.
This document describes the software test plan for VERAIn and provides appendices for the software requirements and software test report. In this document, the test platform hardware and software are described. Appendix A provides a list of the tests run and their acceptability as a test report, and Appendix B provides the list of low-level software requirements as a requirements traceability matrix.
By integrating the attitude determination and control system (ACS) analysis and design, flight software development, and flight software testing processes, it is possible to improve the overall spacecraft development cycle, as well as allow for more thorough software testing. One of the ways to achieve this integration is to use code-generation tools to automatically generate components of the ACS flight software directly from a high-fidelity (HiFi) simulation. In the development of the Microwave Anisotropy Probe (MAP) spacecraft, currently underway at the NASA Goddard Space Flight Center, approximately 1/3 of the ACS flight software was automatically generated. In this paper, we will examine each phase of the ACS subsystem and flight software design life cycle: analysis, design, and testing. In the analysis phase, we scoped how much software we would automatically generate and created the initial interface. The design phase included parallel development of the HiFi simulation and the hand-coded flight software components. Everything came together in the test phase, in which the flight software was tested, using results from the HiFi simulation as one of the bases of comparison for testing. Because parts of the spacecraft HiFi simulation were converted into flight software, more care needed to be put into its development and configuration control to support both the HiFi simulation and flight software. The components of the HiFi simulation from which code was generated needed to be designed based on the fact that they would become flight software. This process involved such considerations as protecting against mathematical exceptions, using acceptable module and parameter naming conventions, and using an input/output interface compatible with the rest of the flight software. Maintaining good configuration control was an issue for the HiFi simulation and the flight software, and a way to track the two systems was devised. Finally, an integrated test approach was devised to support flight software testing at both the unit- and build-test levels using the HiFi simulation to generate data for performance verification. Another benefit of the simulation and code-generation application used on the MAP project is that it supported bringing flight software and test data into the HiFi simulation environment. It was possible to integrate parts of the hand-coded flight software into the HiFi simulation, and also possible to import flight software test data for comparison and performance verification. This capability was used to incorporate the flight software Kalman filter into the HiFi simulation. This enabled us to greatly increase the amount of testing that could be done on the filter, because we could exert a greater degree of control over the software-only simulation than over the flight software test environment. Also, since the simulation could be used to run the Kalman filter faster than real time, our testing efficiency was greatly increased. We will conclude our discussion with a summary of the lessons learned thus far using automatically- generated code for the MAP project, and the spacecraft status as we work towards our scheduled launch in the year 2000.
This document details the software requirements, test plan, and test results for VERAView. In this document, the test platform hardware and software are described. Section 2 provides a list of the tests run and their acceptability as a test report. Section 3 provides the step-by-step execution of these tests and their results.
Materials Testing Software system designed to simplify and automate both routine and not-so-routine materials-testing tasks encountered in laboratory. Supports plan/test/analyze cycle through collection of programs, each optimized to specific task. Gives precise control over nature of command waveforms and acquisition of data, including dynamically variable waveform types, sets of data-acquisition channels, and data rates. Differing command and data-acquisition rates required for exploring creep and fatigue material behavior easily accommodated. Written in Modula-2.
The purpose of this document is to detail the software testing of FAST-1.0 through unit, integration, and assessment tests. More than 400 tests were designed to provide coverage of the requirements for FAST-1.0. These requirements were developed in the NRC Statement of Work (SOW) for NRC Agreement Number NRC-HQ-25-14-D-001 and are transcribed to this document as part of the Software Quality Assurance Plan for the FAST Code System, PNNL-28767. FAST 1.0 represents the merger of the FRAPCON and FRAPTRAN codes and as such FAST-1.0 performs steady state and transient fuel performance calculations described below. FAST-1.0 calculates the steady state response of light-water reactor fuel rods during long-term burnup. The code calculates temperature, pressure, and deformation of a fuel rod as functions of time-dependent fuel rod power and coolant boundary conditions. The phenomena modeled by the code include: 1) heat conduction through fuel and cladding to the coolant; 2) cladding elastic and plastic deformation; 3) fuel-cladding mechanical interaction; 4) fission gas release from the fuel and rod internal pressure; and 5) cladding oxidation. FAST is used to perform independent calculations for regulatory evaluations of fuel performance under normal operation and anticipated operational occurrences (AOOs). FAST calculates the temperature and deformation history of a fuel rod as a function of time-dependent fuel rod power and coolant boundary conditions. The phenomena modeled by FAST include: 1) heat conduction; 2) heat transfer from cladding to coolant; 3) elastic-plastic fuel and cladding deformation; 4) cladding oxidation; 5) fission gas release; and 6) fuel rod gas pressure. FAST code assessment, development and maintenance drive a significant portion of the NRC fuel research activities and the tools are used in a substantial number of regulatory products. Given the centrality of the FAST code to the effectiveness of fuel research, it is critical to assess, develop and maintain this tool.
Over the course of 60 years of shape memory alloy research and development, the properties of these alloys have been measured using various testing methods, which are often customized by the organization performing the test. However, commercial adoption of shape memory alloys in aeronautic actuator applications requires reducing property uncertainty through standardizing test methods. Historically, differential scanning calorimetry (DSC) has been used to measure transformation temperatures under stress-free conditions. This testing method is well established, and tests are run under the applicable standard, ASTM F2004-17: Standard Test Method for Transformation Temperature of Nickel-Titanium Alloys by Thermal Analysis. Two other test methods for measuring strains and transformation temperatures under constant load or free recovery after prestraining have only recently been standardized—ASTM E3097: Standard Test Method for Mechanical Uniaxial Constant Force Thermal Cycling of SMAs (UCFTC) and ASTM E3098: Standard Test Method for Mechanical Uniaxial Pre-Strain and Thermal Free Recovery of SMAs (UPFR). These standards represent a critical step forward in producing reliable material property data for the use of these alloys in aeronautics and other commercial areas. However, no standard programs or software packages were previously available for postprocessing UCFTC- and UPFR-type test data to extract property data. Each organization that performed the testing analyzed data using its own custom manual methods, such as using a plot and a straight edge, spreadsheet plotting methods, or custom code routines, to extract the required values for strains, stresses, and transformation temperatures. SMAnalytics represents the first publicly available uniform software package for processing data generated using the DSC, UCFTC, and UPFR test methods, as well as many modifications of these methods, including loading in martensite versus austenite and performing multiple thermal cycles at stress. In doing so, it provides a tool for reducing potential error or variability in the measured values due to the precision of the technique used and person-to-person variability. It is also expected that this automated data-parsing tool can accelerate the data analysis phase of the test campaign, especially for large data files. This User’s Manual describes how the SMAnalytics software works and the method for its use.
A validation procedure for the Ada binding of the Graphical Kernel System (GKS) is being developed. PRIOR Data Sciences is also producing a version of the GKS written in Ada. These major software engineering projects will provide an opportunity to demonstrate a sound approach for software testing in an Ada environment. The GKS/Ada validation capability will be a collection of test programs and data, and test management guidelines. These products will be used to assess the correctness, completeness, and efficiency of any GKS/Ada implementation. The GKS/Ada developers will be able to obtain the validation software for their own use. It is anticipated that this validation software will eventually be taken over by an independent standards body to provide objective assessments of GKS/Ada implementations, using an approach similar to the validation testing currently applied to Ada compilers. In the meantime, if requested, this validation software will be used to assess GKS/Ada products. The second project, implementation of GKS using the Ada language, is a conventional software engineering tasks. It represents a large body of Ada code and has some interesting testing problems associated with automatic testing of graphics routines. Here the normal test practices which include automated regression testing, independent quality assistance, test configuration management, and the application of software quality metrics will be employed. The software testing methods emphasize quality enhancement and automated procedures. Ada makes some aspects of testing easier, and introduces some concerns. These issues are addressed.
In the aerospace domain, software test plays a more important role more than expected. In this session, NASA introduce why and how they use software test at NASA's IVV program.
The Imaging for Hypersonic Experimental Aeroheating Testing (IHEAT) software is used at the NASA Langley Research Center to analyze global aeroheating data on wind tunnel models tested in the Langley Aerothermodynamics Laboratory. One-dimensional, semi-infinite heating data derived from IHEAT are used in the design of thermal protection systems for hypersonic vehicles that are exposed to severe aeroheating loads, such as reentry vehicles during descent and landing procedures. This software program originally was written in the PV-WAVE(Registered Trademark) programming language to analyze phosphor thermography data from the two-color, relative-intensity system developed at Langley. To increase the efficiency, functionality, and reliability of IHEAT, the program was migrated to MATLAB(Registered Trademark) syntax and compiled as a stand-alone executable file labeled version 4.0. New features of IHEAT 4.0 include the options to perform diagnostic checks of the accuracy of the acquired data during a wind tunnel test, to extract data along a specified multi-segment line following a feature such as a leading edge or a streamline, and to batch process all of the temporal frame data from a wind tunnel run. Results from IHEAT 4.0 were compared on a pixel level to the output images from the legacy software to validate the program. The absolute differences between the heat transfer data output from the two programs were on the order of 10(exp -5) to 10(exp -7). IHEAT 4.0 replaces the PV-WAVE(Registered Trademark) version as the production software for aeroheating experiments conducted in the hypersonic facilities at NASA Langley.