Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software Test Tool”

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 577 records · Page 32
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Hindlimb Suspension as a Model to Study Ophthalmic Complications in Microgravity Status Report: Optimization of Rat Retina Flat Mounts Staining to Study Vascular Remodeling

Preliminary data from a prior tissue‐sharing experiment has suggested that early growth response protein‐1 (Egr1), a transcription factor involved in various stress responses in the vasculature, is induced in the rat retina after 14 days of hindlimb suspension (HS) and may be evidence that mechanical stress is occurring secondary to the cephalad fluid shift. This mechanical stress could cause changes in oxygenation of the retina, and the subsequent ischemia‐ or inflammation‐driven hypoxia may lead to microvascular remodeling. This microvascular remodeling process can be studied using image analysis of retinal vessels and can be then be quantified by the VESsel GENeration Analysis (VESGEN) software, a computational tool that quantifies remodeling patterns of branching vascular trees and capillary or vasculogenic networks. Our project investigates whether rodent HS is a valid model to study the effects of simulated‐weightlessness on ocular structures and their relationship with intracranial pressure (ICP). One of the hypotheses to be tested is that HS‐induced cephalad fluid shift is accompanied by vascular engorgement that produces changes in retinal oxygenation, leading to oxidative stress, hypoxia, microvascular remodeling, and cellular degeneration. We have optimized the procedure to obtain flat mounts of rat retina, staining of the endothelial lining in vasculature and acquisition of high quality images suitable for VESGEN analysis. Briefly, eyes were fixed in 4% paraformaldehyde for 24 hours and retinas were detached and then mounted flat on microscope slides. The microvascular staining was done with endothelial cell‐specific isolectin binding, coupled to Alexa‐488 fluorophore. Image acquisition at low magnification and high resolution was performed using a new Leica SP8 confocal microscope in a tile pattern across the X,Y plane and multiple sections along the Z‐axis. This new confocal microscope has the added capability of dye separation using the Linear Unmixing method and allows us to remove the autofluorescence originating from the photoreceptor layer. In summary, we have an improved method for studying the retinal microvasculature that will provide an increase in the quality of images captured and will be applied throughout the various animal cohorts of the recentlyinitiated study that will evaluate rodent HS as a model to study ophthalmic complications in microgravity.

Theriot, Corey A.↗
NASA NTRSDate not supplied

An Agile-Like Approach to Hardware Development: The Ejectable Data Recorder (EDR) for Orion's Ascent Abort 2 (AA-2) Test Flight

On July 2, 2019, the Ascent Abort 2 (AA-2) Flight Test Vehicle was launched from Cape Canaveral, with the goal of demonstrating the performance of Orion’s Launch Abort System (LAS) and collecting data from hundreds of sensors throughout the vehicle. The data collected during this test flight is of paramount importance, as it will be used to certify the Orion vehicle for human spaceflight. Originally, the data was to be downlinked via a single string network of antennas on the LAS, with the associated risk of potential data dropouts, as well as loss of data once the LAS was jettisoned. Thus, additional antennas were added onto the crew module (CM) to support data downlink post-LAS jettison, a buffer rebroadcast capability was added to fill in any gaps in data downlink transmissions, and an ejectable data recorder (EDR) subsystem was added to the CM as a redundant measure to collect all the instrumentation data. The EDR subsystem was added to the project about one year after the project commenced, which significantly reduced the available development time when compared with the other subsystems of the AA-2 Test Flight. The project was further accelerated by six months, around the critical design review gate. Due to the schedule compression challenge and the fact that the EDR subsystem was a backup system and not flight critical, the EDR subsystem was further challenged to find a new and more efficient way to develop hardware. Thus, the EDR subsystem experimented with different management and systems engineering processes, team sizes, communication methods, and tools. Some examples are novel uses of SharePoint as a Data-centric Project Management & Systems Engineering environment, a continuous testing approach through the lifecycle, and a Skunkworks approach to managing the team. The EDR subsystem blended Commercial Off The Shelf (COTS) hardware with in-house developed hardware and software to create a novel data retrieval capability. The capability evolved rapidly through a hardware in the loop simulation environment that enabled incremental component updates for not only the EDR subsystem but across the entire Crew Module. This paper will present an overview of how the EDR subsystem was managed and compare it to an Agile approach to managing projects. The paper will further provide a recommended approach to future Agile-like hardware development that incorporates lessons learned from the EDR experience.

Agile↗
NASA NTRS2018

Multiple Uplinks Per Antenna (MUPA) Signal Acquisition Schemes

The Deep Space Network (DSN) currently makes use of the technique of Multiple Spacecraft per Antenna (MSPA) where a single antenna is used to track multiple spacecraft downlinks within its beam, such as in the case of multiple spacecraft orbiting Mars at 8.4 GHz (X-band). It is desired to extend this technique to the uplink where a single station is used to send a signal to multiple spacecraft in order to make more efficient use of ground resources. This would be applicable to numerous smallsat constellations being considered for future missions or to future spacecraft at Venus, Mars, or more distant destinations that are all within the half-power beamwidth of a single 34-m diameter antenna. In one scheme, each spacecraft’s command sequences would be time multiplexed onto a single uplink frequency. Each spacecraft would lock onto the uplink signal and would accept only commands intended for it via special identifier codes. Each spacecraft would also emit a downlink signal to the ground that is coherent with the uplink signal but would have its own allocated frequency channel and identifier information. A couple of key challenges associated with using this technique need to be addressed. Because of the single uplink frequency, coherent turnaround for two-way Doppler and ranging would not conform to established ratios, thus the radios employed by the spacecraft would need to be capable of variable turnaround ratios. In addition, because of the different orbits or spacecraft trajectories, the relative Doppler shifts and rates can be large with respect to the common uplink signal whose frequency would lie at the centroid of the frequencies of the expected received signals of the constellation. This would be problematic with standard analog spacecraft radios whose acquisition bandwidths are relatively small (~1.7 kHz) relative to the large frequency offsets (~100 kHz) expected using the single frequency uplink technique. With the advent of software defined radios (SDRs), signal frequency search algorithms can be utilized within the flight software and/or programmable hardware (e.g., FPGAs) that can easily acquire and track signals with large frequency offsets and varying dynamics. Such techniques could include FFT search algorithms, step-and-sweep search algorithms, or onboard frequency steering making use of trajectory vectors uplinked to each member spacecraft. Other challenges include mitigation of potential interference between received signals. We have identified several software defined radios that are in different stages of development and whose key parameters have been tabulated. We have examined each radio’s capabilities with respect to acquiring and tracking signals with large frequency offsets. Such analyses made use of previous studies supplemented with specially designed tests using both simulation tools and/or existing testbeds. We have compared signal acquisition times computed from provided algorithms along with measured values derived from tests using existing hardware and simulation tools for the purpose of conducting tradeoff studies between the various radio designs and software/firmware programming approaches.

Abraham, Douglas S.↗
NASA NTRS2020

A ROS-based Simulator for Testing the Enhanced Autonomous Navigation of the Mars 2020 Rover

In order to achieve the ambitious objectives of the Mars 2020 (M2020) mission, in particular the ability to autonomously traverse more challenging terrains more efficiently, new surface mobility software was developed for Enhanced Navigation (ENav). That decision was made early in the project, before most of the new surface flight software (FSW) existed, which created a need for a separate framework where the new navigation algorithms could be quickly prototyped and tested, before more realistic FSW-based testbeds became available. The JPL robotics team chose the Robot Operating System [1] (ROS) as the environment in which to test the new ENav algorithms. This made it possible to write the algorithms in the C language required by the FSW, so they could be directly ported over to the flight module later on, while leveraging all the C++ libraries and tools provided by ROS for simulation and testing. The ENav algorithms were developed as a separate C library, and stubs were used to replace any FSW-specific code, such as Event Reporting (EVRs) and data products (DPs). A ROS simulator was developed to generate a rich set of varied 3D terrains representative of the candidate Mars landing sites and simulate the physics of the rover motion, the point cloud perceived by the rover’s stereo vision system, and the new thinking-while-driving (TWD) navigation logic which directs the rover to drive autonomously to user-specified waypoints. To simulate the rover motion and perception, a ROS node was developed that uses a software library called HyperDrive Sim (HDSim), which is a wrapper for the Rover Sequencing and Visualization Program [2] (RSVP). That library provides roverterrain settling, realistic slip modelling, and camera rendering capability based on the rover’s NavCam machine vision models. To simulate the navigation logic, a ROS node was created that initializes and runs the ENav algorithms in a way that mimics the FSW execution, while also providing the capability to load and replay data products, including re-running the recorded inputs through the ENav algorithms for testing. An engineering Graphical User Interface (GUI) was also developed to visualize various elements, such as the rover pose during the drive, the simulated and perceived terrain, the selected local and global paths to the goal, the evaluated candidate paths and the reasons why they were rejected, the keep-in and keep-out zones (KIOZs), etc. Finally, an advanced Monte Carlo (MC) framework that can run many simulations in parallel on the Cloud and automatically generate reports that capture the key ENav performance metrics was developed to evaluate the system in a statisticallymeaningful way. This paper provides an overview of the ROSbased simulator used for testing the M2020 ENav algorithms.

Toupet, Olivier↗
NASA NTRS2024

Historical Aerospace Software Errors Categorized to Influence Fault Tolerance

Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in mission or safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes a set of 55 historic aerospace software error incidents from 1962 to 2023 to determine trends of how and where automation is most likely to fail, behaving unexpectedly. A distinction between software producing unexpected (erroneous) output versus no output (failsilent) is introduced. Of the historical incidents analyzed, 85% were from software producing wrong output rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and not reliable to recover from silent failures. Error origin was within the code/logic itself in 58% of cases, 16% from configurable data, 15% from unexpected sensor input, and 11% from command/operator input. A substantial forty percent (40%) of unexpected software behavior was indicated by the absence of code, arising from unanticipated situations and missing requirements, and 16% of incidents were subjectively deemed “unknown-unknowns”. No incidents were found to be the result of programming language, compiler, tool, or operating system; and only sixteen percent (16%) of all incidents were considered errors traditional computer science/programming in nature. These findings indicate that for fault tolerance, erroneous automation behavior must be a primary consideration especially at critical moments, and reboot recoverability may not be viable. Special care should be taken to validate configurable data and commands prior to use. “Test-like-you-fly”, including hardware-in-the-loop combined with robust off-nominal testing should be used to uncover missing logic arising from unanticipated situations not covered by requirements alone. This study uniquely focuses on manifestations of unexpected flight software behavior, independent of ultimate root cause. We characterize software error behavior and origin to improve software design, test, and operations for resilience to the most common manifestations, and provide a rich dataset for further study.

Aerospace↗
NASA NTRS2021

Terminal Descent Radar System Testbed for Future Planetary Landers

Terminal Descent Radars (TDR), or landing radars, have been an integral element of Guidance, Navigation and Control (GN\&C) sensor suites of robotic exploration missions to the Moon and Mars. As plans for new, exciting exploration missions to the Moon, Mars and other planetary bodies are being developed, there is a need for a new generation of TDRs that are smaller, consume less power and are less expensive than previous sensors. The challenge of designing such a landing sensor is twofold: the first is to have well-vetted software tools that allow us to explore the design space for a particular mission scenario and analyze performance of relevant radar architectures. The second challenge is to reduce mass and power requirements of a landing radar without compromising reliability and performance. New design approaches that address these challenges need to be tested and demonstrated in realistic Entry-Descent-Landing (EDL)/Deorbit-Descent-Landing (DDL) scenarios. In this paper, we describe a TDR testbed developed at the Jet Propulsion Laboratory. The testbed is a closed-loop design, analysis and verification capability used to design and evaluate the next generation of landing radars for a variety of EDL/DDL scenarios.

Tope, Michael↗
NASA NTRS2021

Terminal Descent Radar System Testbed for Future Planetary Landers

Terminal Descent Radars (TDR), or landing radars, have been an integral element of Guidance, Navigation and Control (GN\&C) sensor suites of robotic exploration missions to the Moon and Mars. As plans for new, exciting exploration missions to the Moon, Mars and other planetary bodies are being developed, there is a need for a new generation of TDRs that are smaller, consume less power and are less expensive than previous sensors. The challenge of designing such a landing sensor is twofold: the first is to have well-vetted software tools that allow us to explore the design space for a particular mission scenario and analyze performance of relevant radar architectures. The second challenge is to reduce mass and power requirements of a landing radar without compromising reliability and performance. New design approaches that address these challenges need to be tested and demonstrated in realistic Entry-Descent-Landing (EDL)/Deorbit-Descent-Landing (DDL) scenarios. In this paper, we describe a TDR testbed developed at the Jet Propulsion Laboratory. The testbed is a closed-loop design, analysis and verification capability used to design and evaluate the next generation of landing radars for a variety of EDL/DDL scenarios.

Tope, Michael↗
NASA NTRSDate not supplied

Flight Software for the LOFTID Re-Entry Vehicle

NASA’s Low-Earth Orbit Flight Test of an Inflatable Decelerator, or LOFTID, demonstrated re-entry from low-Earth orbit of a 6-meter aeroshell designed to be used as a heat shield that is larger than the rocket shroud, enabling the return of much greater mass. The LOFTID Flight Software was developed in-house and consists of three components: the Power Distribution software, the Data Recorder software, and the Camera Controller software, along with the Ground Software used for testing, operations, data integrity, and data processing. This presentation will discuss issues found in developing the Power Distribution software in cFS on a non-Linux POSIX platform, designing an efficient architecture for recording of high bandwidth data, controlling over a dozen cameras in-flight, and creating the ground support tools to verify data integrity and support the post-processing of flight data.

Paul Brewster↗
DOE OSTI2025

Code Coverage Status of the ARC Code RCT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. REBUS plays a pivotal role in the ARC system as the primary fuel cycle analysis capability for fast reactor problems. Over its 60 year history, ARC software usage with REBUS has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. The RCT code is a later addition and uses the REBUS restart files to define its input. The RCT code was built to provide pin depletion details on EBR-II models and thus many features of RCT were specifically tailored to the needs of EBR-II models. Additional approximations were invoked which are likely only valid for the EBR-II reactor and the particular fuel management that was done for it. The purpose of the present work is to identify a set of test problems for RCT and assess the code coverage for those test problems. The goal is to document what parts of the existing RCT code are touched by the set of test problems and which are not. Because no detailed verification work has been done on RCT, the existing regression testing suite was chosen for the code coverage assessment. The code coverage analysis of RCT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of RCT. The detailed coverage tables are given for each part of RCT. As will be discussed and shown, some parts of the RCT capability that are known to be used by the EBR-II analysis work are not tested by the regression testing suite. These aspects should be resolved before major source code changes are taken for the RCT software. Because REBUS and DIF3D are not subroutines of RCT, the coverage changes in both of those codes is not altered by RCT. The same is true for all of the modules of DIF3D that are used by RCT such as SYSLIB and SEGLIB.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRSDate not supplied

Assessing Engine Hot Fire Data for Human Spaceflight Applications

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

Data Assessment↗
NASA NTRSDate not supplied

Assessing Engine Hot Fire Data for Human Spaceflight Applications

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

Data Assessment↗
DOE OSTI2025

ComPort: Rigorous Testing Methods to Safeguard Software Porting (Final UW Report)

This report summarizes the University of Washington’s contributions to the ComPort project, Rigorous Testing Methods to Safeguard Software Porting, funded under the U.S. Department of Energy, Office of Science, Office of Advanced Scientific Computing Research (ASCR), award number DE-SC0022081. UW’s work addressed numerics-driven correctness challenges arising in heterogeneous and rapidly evolving computing environments. Our efforts focused on developing interactive analysis tools, correctness-preserving rewriting systems, semantic-aware code-transformation infrastructure, and multi-language support for reproducible numerical experiments.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2001

Legato: Personal Computer Software for Analyzing Pressure-Sensitive Paint Data

'Legato' is personal computer software for analyzing radiometric pressure-sensitive paint (PSP) data. The software is written in the C programming language and executes under Windows 95/98/NT operating systems. It includes all operations normally required to convert pressure-paint image intensities to normalized pressure distributions mapped to physical coordinates of the test article. The program can analyze data from both single- and bi-luminophore paints and provides for both in situ and a priori paint calibration. In addition, there are functions for determining paint calibration coefficients from calibration-chamber data. The software is designed as a self-contained, interactive research tool that requires as input only the bare minimum of information needed to accomplish each function, e.g., images, model geometry, and paint calibration coefficients (for a priori calibration) or pressure-tap data (for in situ calibration). The program includes functions that can be used to generate needed model geometry files for simple model geometries (e.g., airfoils, trapezoidal wings, rotor blades) based on the model planform and airfoil section. All data files except images are in ASCII format and thus are easily created, read, and edited. The program does not use database files. This simplifies setup but makes the program inappropriate for analyzing massive amounts of data from production wind tunnels. Program output consists of Cartesian plots, false-colored real and virtual images, pressure distributions mapped to the surface of the model, assorted ASCII data files, and a text file of tabulated results. Graphical output is displayed on the computer screen and can be saved as publication-quality (PostScript) files.

Schairer, Edward T.↗
NASA NTRS2004

A Re-programmable Platform for Dynamic Burn-in Test of Xilinx Virtexll 3000 FPGA for Military and Aerospace Applications

Field Programmable Gate Arrays (FPGA) have played increasingly important roles in military and aerospace applications. Xilinx SRAM-based FPGAs have been extensively used in commercial applications. They have been used less frequently in space flight applications due to their susceptibility to single-event upsets. Reliability of these devices in space applications is a concern that has not been addressed. The objective of this project is to design a fully programmable hardware/software platform that allows (but is not limited to) comprehensive static/dynamic burn-in test of Virtex-II 3000 FPGAs, at speed test and SEU test. Conventional methods test very few discrete AC parameters (primarily switching) of a given integrated circuit. This approach will test any possible configuration of the FPGA and any associated performance parameters. It allows complete or partial re-programming of the FPGA and verification of the program by using read back followed by dynamic test. Designers have full control over which functional elements of the FPGA to stress. They can completely simulate all possible types of configurations/functions. Another benefit of this platform is that it allows collecting information on elevation of the junction temperature as a function of gate utilization, operating frequency and functionality. A software tool has been implemented to demonstrate the various features of the system. The software consists of three major parts: the parallel interface driver, main system procedure and a graphical user interface (GUI).

Field Programmable Gate Arrays (FPGA)↗
NASA NTRS2011

Enterprise Reference Library

Introduction: Johnson Space Center (JSC) offers two extensive libraries that contain journals, research literature and electronic resources. Searching capabilities are available to those individuals residing onsite or through a librarian s search. Many individuals have rich collections of references, but no mechanisms to share reference libraries across researchers, projects, or directorates exist. Likewise, information regarding which references are provided to which individuals is not available, resulting in duplicate requests, redundant labor costs and associated copying fees. In addition, this tends to limit collaboration between colleagues and promotes the establishment of individual, unshared silos of information The Integrated Medical Model (IMM) team has utilized a centralized reference management tool during the development, test, and operational phases of this project. The Enterprise Reference Library project expands the capabilities developed for IMM to address the above issues and enhance collaboration across JSC. Method: After significant market analysis for a multi-user reference management tool, no available commercial tool was found to meet this need, so a software program was built around a commercial tool, Reference Manager 12 by The Thomson Corporation. A use case approach guided the requirements development phase. The premise of the design is that individuals use their own reference management software and export to SharePoint when their library is incorporated into the Enterprise Reference Library. This results in a searchable user-specific library application. An accompanying share folder will warehouse the electronic full-text articles, which allows the global user community to access full -text articles. Discussion: An enterprise reference library solution can provide a multidisciplinary collection of full text articles. This approach improves efficiency in obtaining and storing reference material while greatly reducing labor, purchasing and duplication costs. Most importantly, increasing collaboration across research groups provides unprecedented access to information relevant to NASA s mission. Conclusion: This project is an expansion and cost-effective leveraging of the existing JSC centralized library. Adding key word and author search capabilities and an alert function for notifications about new articles, based on users profiles, represent examples of future enhancements.

Bickham, Grandin↗
NASA NTRSDate not supplied

Understanding and Verifying Neural Networks

Deep Neural Networks (DNNs) have gained immense popularity in recent times and have widespread use in applications such as image classification, sentiment analysis, speech recognition and also in safety-critical applications such as autonomous driving. However, they suffer limitations such as lack of explainability and robustness which raise safety and security concerns in their usage. Further, the complex structure and large input spaces of DNNs act as an impediment to thorough verification and testing. The SafeDNN project at the Robust Software Engineering (RSE) group at NASA aims at exploring techniques to ensure that systems that use deep neural networks are safe, robust and interpretable. In this talk, I will be presenting our technique Prophecy that automatically infers formal properties of deep neural network models. The tool extracts patterns based on neuron activations as preconditions that imply certain desirable output properties of the model. I would be highlighting case studies that use Prophecy in obtaining explanations for network decisions, understanding correct and incorrect behavior, providing formal guarantees wrt safety and robustness, and debugging neural network models. We have applied the tool on image classification networks, neural network controllers providing turn advisories in unmanned aircrafts, regression models used for autonomous center-line tracking in aircrafts and neural network object detectors

Deep Neural Networks↗
NASA NTRSDate not supplied

Applying Formal Methods to Safety-Critical Systems

How do you know a proof is correct? Traditionally, mathematical proofs are socially verified – at least one human, following a set of implicit rules of natural language and logic, determines if the proof is believable. If the proof becomes overly tedious and/or is essential to some safety- or mission-critical application, it becomes necessary to determine the soundness to a higher standard. 'Formal methods' refer to mathematically rigorous techniques and tools that enable specification, design, and verification of hardware and software systems. The specification used in formal methods are statements in a mathematical logic while the formal verifications are deductions in that logic. Formal methods can be difficult or time/resource intensive, but offer a higher level of assurance than standard verification through testing or handwritten proofs. This talk will introduce formal methods, motivated by applications of interest to NASA, including uncrewed aircraft operations in the national airspace, urban air environments, and wildfire areas. The audience will be given a crash course in mechanically verified proofs in the Prototype Verification System (PVS), an interactive theorem prover.

Formal Methods↗
NASA NTRSDate not supplied

Assessing Hot Fire Data with WinPlot

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health and performance pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

J. Davis Hunter↗