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 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

CFD Fuel Slosh Modeling of Fluid-Structure Interaction in Spacecraft Propellant Tanks with Diaphragms

Liquid sloshing within spacecraft propellant tanks causes rapid energy dissipation at resonant modes, which can result in attitude destabilization of the vehicle. Identifying resonant slosh modes currently requires experimental testing and mechanical pendulum analogs to characterize the slosh dynamics. Computational Fluid Dynamics (CFD) techniques have recently been validated as an effective tool for simulating fuel slosh within free-surface propellant tanks. Propellant tanks often incorporate an internal flexible diaphragm to separate ullage and propellant which increases modeling complexity. A coupled fluid-structure CFD model is required to capture the damping effects of a flexible diaphragm on the propellant. ANSYS multidisciplinary engineering software employs a coupled solver for analyzing two-way Fluid Structure Interaction (FSI) cases such as the diaphragm propellant tank system. Slosh models generated by ANSYS software are validated by experimental lateral slosh test results. Accurate data correlation would produce an innovative technique for modeling fuel slosh within diaphragm tanks and provide an accurate and efficient tool for identifying resonant modes and the slosh dynamic response.

Sances, Dillon J.↗
NASA NTRS1996

Cassini Star Tracking and Identification Algorithms, Scene Simulation, and Testing

The Cassini mission will use autonomous star identification for initial attitude determination and a star tracking function for maintaining attitude. Because of the complexity of the StarID software, special software simulation tools were created to simulate the Stellar Reference Unit (SRU) output as a function of commands, spacecraft attitude, and star scene, and to allow the introduction of fault conditions. This paper gives the overview of the algorithm design and SRU simulation and a description of the simulation test results and a comparison with field test results obtained using the engineering model SRU.

Cassini↗
NASA NTRS1988

Western aeronautical test range real-time graphics software package MAGIC

The master graphics interactive console (MAGIC) software package used on the Western Aeronautical Test Range (WATR) of the NASA Ames Research Center is described. MAGIC is a resident real-time research tool available to flight researchers-scientists in the NASA mission control centers of the WATR at the Dryden Flight Research Facility at Edwards, California. The hardware configuration and capabilities of the real-time software package are also discussed.

Malone, Jacqueline C.↗
NASA NTRS2002

A Facility and Architecture for Autonomy Research

Autonomy is a key enabling factor in the advancement of the remote robotic exploration. There is currently a large gap between autonomy software at the research level and software that is ready for insertion into near-term space missions. The Mission Simulation Facility (MST) will bridge this gap by providing a simulation framework and suite of simulation tools to support research in autonomy for remote exploration. This system will allow developers of autonomy software to test their models in a high-fidelity simulation and evaluate their system's performance against a set of integrated, standardized simulations. The Mission Simulation ToolKit (MST) uses a distributed architecture with a communication layer that is built on top of the standardized High Level Architecture (HLA). This architecture enables the use of existing high fidelity models, allows mixing simulation components from various computing platforms and enforces the use of a standardized high-level interface among components. The components needed to achieve a realistic simulation can be grouped into four categories: environment generation (terrain, environmental features), robotic platform behavior (robot dynamics), instrument models (camera/spectrometer/etc.), and data analysis. The MST will provide basic components in these areas but allows users to plug-in easily any refined model by means of a communication protocol. Finally, a description file defines the robot and environment parameters for easy configuration and ensures that all the simulation models share the same information.

Pisanich, Greg↗
NASA NTRS2005

Requirements to Design to Code: Towards a Fully Formal Approach to Automatic Code Generation

A general-purpose method to mechanically transform system requirements into a provably equivalent model has yet to appear. Such a method represents a necessary step toward high-dependability system engineering for numerous possible application domains, including distributed software systems, sensor networks, robot operation, complex scripts for spacecraft integration and testing, and autonomous systems. Currently available tools and methods that start with a formal model of a system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The gap that current tools and methods leave unfilled is that their formal models cannot be proven to be equivalent to the system requirements as originated by the customer. For the classes of systems whose behavior can be described as a finite (but significant) set of scenarios, we offer a method for mechanically transforming requirements (expressed in restricted natural language, or in other appropriate graphical notations) into a provably equivalent formal model that can be used as the basis for code generation and other transformations.

Hinchey, Michael G.↗
NASA NTRS2011

Improvements to the Ionizing Radiation Risk Assessment Program for NASA Astronauts

To perform dosimetry and risk assessment, NASA collects astronaut ionizing radiation exposure data from space flight, medical imaging and therapy, aviation training activities and prior occupational exposure histories. Career risk of exposure induced death (REID) from radiation is limited to 3 percent at a 95 percent confidence level. The Radiation Health Office at Johnson Space Center (JSC) is implementing a program to integrate the gathering, storage, analysis and reporting of astronaut ionizing radiation dose and risk data and records. This work has several motivations, including more efficient analyses and greater flexibility in testing and adopting new methods for evaluating risks. The foundation for these improvements is a set of software tools called the Astronaut Radiation Exposure Analysis System (AREAS). AREAS is a series of MATLAB(Registered TradeMark)-based dose and risk analysis modules that interface with an enterprise level SQL Server database by means of a secure web service. It communicates with other JSC medical and space weather databases to maintain data integrity and consistency across systems. AREAS is part of a larger NASA Space Medicine effort, the Mission Medical Integration Strategy, with the goal of collecting accurate, high-quality and detailed astronaut health data, and then securely, timely and reliably presenting it to medical support personnel. The modular approach to the AREAS design accommodates past, current, and future sources of data from active and passive detectors, space radiation transport algorithms, computational phantoms and cancer risk models. Revisions of the cancer risk model, new radiation detection equipment and improved anthropomorphic computational phantoms can be incorporated. Notable hardware updates include the Radiation Environment Monitor (which uses Medipix technology to report real-time, on-board dosimetry measurements), an updated Tissue-Equivalent Proportional Counter, and the Southwest Research Institute Radiation Assessment Detector. Also, the University of Florida hybrid phantoms, which are flexible in morphometry and positioning, are being explored as alternatives to the current NASA computational phantoms.

Semones, E. J.↗
NASA NTRS2005

Requirements to Design to Code: Towards a Fully Formal Approach to Automatic Code Generation

A general-purpose method to mechanically transform system requirements into a provably equivalent model has yet to appear. Such a method represents a necessary step toward high-dependability system engineering for numerous possible application domains, including distributed software systems, sensor networks, robot operation, complex scripts for spacecraft integration and testing, and autonomous systems. Currently available tools and methods that start with a formal model of a: system and mechanically produce a provably equivalent implementation are valuable but not sufficient. The "gap" that current tools and methods leave unfilled is that their formal models cannot be proven to be equivalent to the system requirements as originated by the customer. For the ciasses of systems whose behavior can be described as a finite (but significant) set of scenarios, we offer a method for mechanically transforming requirements (expressed in restricted natural language, or in other appropriate graphical notations) into a provably equivalent formal model that can be used as the basis for code generation and other transformations.

Hinchey, Michael G.↗
NASA NTRSDate not supplied

Updates on the Predictive Materials Modeling Software Tools

Updates on NASA‘s efforts to build a Predictive Material Modeling (PMM) framework from the micro-scale to the macro-scale are presented in this abstract. The PMM effort is part of the Entry Systems Modeling (ESM) project under NASA’s Game Changing Development (GCD) program. To reduce the need for extensive testing and accelerate the design cycle process, ESM is developing simulation and modeling tools that enable the characterization of the properties of thermal protection materials and their response to extremely hot plasma. The Porous Microstructure Analysis (PuMA) software has been developed to compute effective material properties and perform material response simulations on digitized microstructures of porous media. PuMA is able to import three-dimensional digital images obtained from X-ray microtomography or to generate artificial microstructures that mimic real materials. PuMA also provides a module for interactive 3D visualizations. Version 3, which was recently released as open-source, includes modules to compute simple morphological properties such as porosity, volume fractions, pore diameter, and specific surface area. Additional capabilities include the determination of effective thermal and electrical conductivity (both radiative and solid conduction - including the ability to simulate local anisotropy for the latter); effective diffusivity and tortuosity from the continuum to the rarefied regime; techniques to determine the local material orientation, as well as mechanical properties (elasticity coefficients), and permeability. Computed properties are then used to inform a macro-scale material response model, such as those implemented in the Porous material Analysis Toolbox based on OpenFOAM (PATO) software developed within ESM. The computational model in PATO is a generic heat and mass transfer model for porous reactive materials containing several solid phases and a single gas phase. The detailed chemical interactions occurring between the solid phases and the gas phase are modeled at the pore scale, assuming Local Thermal Equilibrium. Recent efforts include the development of a mechanical erosion model as well as a unified model allowing an intrinsic coupling between fluid and material. Comparison to flight data (Mars Science Laboratory [MSL] Entry Descent and Landing Instrument [MEDLI] and Mars 2020 MEDLI2) is critical in order to validate these computational tools. Examples of ablative material response using the code will be presented, including 3D simulations of the full-scale heatshield of the MSL capsule. The simulations demonstrated the ability of the modern material response code, PATO, to handle the material response of geometrically complex and large domains through the use of massively parallel computations.

material modeling↗
NASA NTRS1989

The use of real-time, hardware-in-the-loop simulation in the design and development of the new Hughes HS601 spacecraft attitude control system

Realtime simulation and hardware-in-the-loop testing is being used extensively in all phases of the design, development, and testing of the attitude control system (ACS) for the new Hughes HS601 satellite bus. Realtime, hardware-in-the-loop simulation, integrated with traditional analysis and pure simulation activities is shown to provide a highly efficient and productive overall development program. Implementation of high fidelity simulations of the satellite dynamics and control system algorithms, capable of real-time execution (using applied Dynamics International's System 100), provides a tool which is capable of being integrated with the critical flight microprocessor to create a mixed simulation test (MST). The MST creates a highly accurate, detailed simulated on-orbit test environment, capable of open and closed loop ACS testing, in which the ACS design can be validated. The MST is shown to provide a valuable extension of traditional test methods. A description of the MST configuration is presented, including the spacecraft dynamics simulation model, sensor and actuator emulators, and the test support system. Overall system performance parameters are presented. MST applications are discussed; supporting ACS design, developing on-orbit system performance predictions, flight software development and qualification testing (augmenting the traditional software-based testing), mission planning, and a cost-effective subsystem-level acceptance test. The MST is shown to provide an ideal tool in which the ACS designer can fly the spacecraft on the ground.

Slafer, Loren I.↗
NASA NTRS1986

Programming support environment issues in the Byron programming environment

Issues are discussed which programming support environments need to address in order to successfully support software engineering. These concerns are divided into two categories. The first category, issues of how software development is supported by an environment, includes support of the full life cycle, methodology flexibility, and support of software reusability. The second category contains issues of how environments should operate, such as tool reusability and integration, user friendliness, networking, and use of a central data base. This discussion is followed by an examination of Byron, an Ada based programming support environment developed at Intermetrics, focusing on the solutions Byron offers to these problems, including the support provided for software reusability and the test and maintenance phases of the life cycle. The use of Byron in project development is described briefly, and some suggestions for future Byron tools and user written tools are presented.

Larsen, Matthew J.↗
NASA NTRS2009

GlastCam: A Telemetry-Driven Spacecraft Visualization Tool

Developed for the GLAST project, which is now the Fermi Gamma-ray Space Telescope, GlastCam software ingests telemetry from the Integrated Test and Operations System (ITOS) and generates four graphical displays of geometric properties in real time, allowing visual assessment of the attitude, configuration, position, and various cross-checks. Four windows are displayed: a "cam" window shows a 3D view of the satellite; a second window shows the standard position plot of the satellite on a Mercator map of the Earth; a third window displays star tracker fields of view, showing which stars are visible from the spacecraft in order to verify star tracking; and the fourth window depicts

Stoneking, Eric T.↗
NASA NTRS2022

Flight Rule Design, Implementation, Verification, and Validation for the Psyche Mission

NASA Jet Propulsion Lab (JPL)’s upcoming mission Psyche will begin its journey to the asteroid (16) Psyche in late 2022 in an effort to better understand its origins and, in turn, better understand our own. Operating the spacecraft safely will require the dedicated efforts of a small team that understands the spacecraft’s operational constraints, as well as a set of powerful spacecraft models designed to catch command errors that can pose risks to mission success. One of the responsibilities of the operations team is to ensure adherence to a set of Flight Rules written by spacecraft and instrument experts that are designed to mitigate these risks. Psyche’s innovations in Flight Rule design principles and advancements in the tools and processes used to implement and check Flight Rules are discussed. A comparison of Psyche’s approach to Flight Rules to other JPL missions will provide lessons learned for future missions that must perform constraint checking during operations. Flight Rule development faces several major challenges. First, flight rule developers must work with Subject Matter Experts (SME) to write the rules in a way that captures the intent of the constraint in a straightforward, enforceable manner. Second, software implementers must correctly interpret flight rules into code so that it meets the original intent of the SME. Finally, a means must be provided for SMEs to validate flight rule implementations without requiring them to understand the underlying software. Innovative processes intended to efficiently close the loop between stakeholders and software developers are described, such as the use of test-driven development to provide stakeholders with easy-to-review implementations. New guidelines for flight rule writing, designed to address these challenges, are described for future missions to adopt and build upon. Psyche Mission System has a variety of new and heritage tools that improve in the Flight Rule validation and checking process. Psyche developed a powerful, new tool called RandSEQ and made significant improvements to Octopusjam, two valuable tools that aid the development of Flight Rule unit tests. Advancements in the models and processes for performing sequence validation with SEQuence GENerator (SEQGEN), the primary, high-heritage tool used for automated flight rule checks on Psyche, are described. The development of new software and the advancements to existing software put Psyche at the forefront of Flight Rule technology. All missions must perform detailed constraint checking, so a comparison of Psyche’s approach to some of these items to the approaches taken by other missions such as Dawn, M2020, and Europa Clipper is done, specifically to examine SME-developer communication, tools used, and development process. Lessons learned from this comparison will be provided.

Weise, Tim↗
NASA NTRS1984

IMCS reflight certification requirements and design specifications

The requirements for reflight certification are established. Software requirements encompass the software programs that are resident in the PCC, DEP, PDSS, EC, or any related GSE. A design approach for the reflight software packages is recommended. These designs will be of sufficient detail to permit the implementation of reflight software. The PDSS/IMC Reflight Certification system provides the tools and mechanisms for the user to perform the reflight certification test procedures, test data capture, test data display, and test data analysis. The system as defined will be structured to permit maximum automation of reflight certification procedures and test data analysis.

Source record↗
NASA NTRS1991

Getting expert systems off the ground: Lessons learned from integrating model-based diagnostics with prototype flight hardware

As an initial attempt to introduce expert system technology into an onboard environment, a model based diagnostic system using the TRW MARPLE software tool was integrated with prototype flight hardware and its corresponding control software. Because this experiment was designed primarily to test the effectiveness of the model based reasoning technique used, the expert system ran on a separate hardware platform, and interactions between the control software and the model based diagnostics were limited. While this project met its objective of showing that model based reasoning can effectively isolate failures in flight hardware, it also identified the need for an integrated development path for expert system and control software for onboard applications. In developing expert systems that are ready for flight, artificial intelligence techniques must be evaluated to determine whether they offer a real advantage onboard, identify which diagnostic functions should be performed by the expert systems and which are better left to the procedural software, and work closely with both the hardware and the software developers from the beginning of a project to produce a well designed and thoroughly integrated application.

Stephan, Amy↗
NASA NTRS2013

Dtest Testing Software

This software runs a suite of arbitrary software tests spanning various software languages and types of tests (unit level, system level, or file comparison tests). The dtest utility can be set to automate periodic testing of large suites of software, as well as running individual tests. It supports distributing multiple tests over multiple CPU cores, if available. The dtest tool is a utility program (written in Python) that scans through a directory (and its subdirectories) and finds all directories that match a certain pattern and then executes any tests in that directory as described in simple configuration files.

Jain, Abhinandan↗
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 NTRS1991

Techniques and implementation of the embedded rule-based expert system using Ada

Ada is becoming an increasingly popular programming language for large Government-funded software projects. Ada with its portability, transportability, and maintainability lends itself well to today's complex programming environment. In addition, expert systems have also assured a growing role in providing human-like reasoning capability and expertise for computer systems. The integration of expert system technology with Ada programming language, specifically a rule-based expert system using an ART-Ada (Automated Reasoning Tool for Ada) system shell is discussed. The NASA Lewis Research Center was chosen as a beta test site for ART-Ada. The test was conducted by implementing the existing Autonomous Power EXpert System (APEX), a Lisp-base power expert system, in ART-Ada. Three components, the rule-based expert system, a graphics user interface, and communications software make up SMART-Ada (Systems fault Management with ART-Ada). The main objective, to conduct a beta test on the ART-Ada rule-based expert system shell, was achieved. The system is operational. New Ada tools will assist in future successful projects. ART-Ada is one such tool and is a viable alternative to the straight Ada code when an application requires a rule-based or knowledge-based approach.

Liberman, Eugene M.↗