Search NASA⌕ Search

SEARCH · Search NASA

Results for “Modeling software”

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 865 records · Page 48
All sourcesNASA NTRSDOE OSTI
NASA NTRS1983

Current research in the Software Engineering Laboratory (SEL)

The basic goal of software engineering is to produce the best possible software at the lowest possible cost. Many practices, tools, and techniques (collectively referred to as technologies) were developed that purport to help do this, some of which have become widely accepted in the software industry. However, few of these technologies were effectively evaluated experimentally. This is due in large part to an insufficient understanding of the software development process, a lack of recognized standards for measurement, and the prohibitive cost of large-scale controlled experiments. The analysis described addresses some of these issues. The specific objectives of this study were to: measure technology use in a production environment; develop a model for evaluating software engineering technologies; and evaluate the effects of productivity and reliability of some specific technologies.

Card, D.↗
NASA NTRS1984

Development of a support software system for real-time HAL/S applications

Methodologies employed in defining and implementing a software support system for the HAL/S computer language for real-time operations on the Shuttle are detailed. Attention is also given to the management and validation techniques used during software development and software maintenance. Utilities developed to support the real-time operating conditions are described. With the support system being produced on Cyber computers and executable code then processed through Cyber or PDP machines, the support system has a production level status and can serve as a model for other software development projects.

Smith, R. S.↗
NASA NTRS2013

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗
NASA NTRS2001

Aviation Safety Simulation Model

The Aviation Safety Simulation Model is a software tool that enables users to configure a terrain, a flight path, and an aircraft and simulate the aircraft's flight along the path. The simulation monitors the aircraft's proximity to terrain obstructions, and reports when the aircraft violates accepted minimum distances from an obstruction. This model design facilitates future enhancements to address other flight safety issues, particularly air and runway traffic scenarios. This report shows the user how to build a simulation scenario and run it. It also explains the model's output.

Houser, Scott↗
NASA NTRS2018

CAIDA CUI Confirmation for OMRS & LCC SOCRRATES Emulator and iSEE Upgrade, Operations, & Analysis

This internship has focused on providing solutions for the Customer Avionics Interface Development and Analysis (CAIDA) subsystem. The main emulator that has been used during this internship is the Software-Only CEV (Crew Exploration Vehicle) Risk Reduction Analysis and Test Engineering Simulator (SOCRRATES). This emulator uses advanced math and physics methods to simulate specific points in a mission, such as ascent, entry, and orbit. Exploration Ground Systems (EGS) must ensure that all KSC based ground systems can be properly integrated with the flight vehicle software, therefore, the Modeling and Simulation Branch (NE-XM) of the KSC (Kennedy Space Center) Engineering Directorate supports a virtual environment that simulates the interface between ground systems and the flight vehicle. A primary component in assuring that is knowing whether the emulators have incorporated the correct CUIs (Compact Unique Identifiers) into their system, as well as understanding both the static and dynamic responses of the individual CUIs. Also, an effort for verification of Operational Maintenance Requirements Specifications (OMRS) and Launch Commit Criteria (LCC) that are supported by SOCRRATES for the Orion Crew Module were part of the project tasks this semester. This internship also focused on comparing two different simulation Commercial-off-the-shelf (COTS) products and to determine whether or not a COTS package was a viable replacement for the current software that the iSEE (Immersive Simulations and Engineering Environment) lab uses. Upon research and testing, I found that this software was not feasible for the lab. It could not easily load CAD (Computer-Aided Design) or CREO models, give live feedback while the user is in the environment, and was not compatible with a virtual reality headset, all of which are necessary for the lab.

Bundy, Caleb↗
NASA NTRSDate not supplied

Model-Based Systems Engineering, Real-Time Operations, and Autonomy

Model-Based Systems Engineering has been enabled by the development of the SysML language and software tools to create systems models. Systems models described in SysML incorporate frames (Diagrams) that represent behaviors (activities, sequences, state machines, use cases), requirements, and structure (definitions, internal structure, parametric formulation, and packaging). The SysML models are, in turn, used by applications to do analysis and studies of the designs and operational capabilities. These uses of the model are based on simulations, and do not include hardware. This paper presents a software environment and processes that enables more comprehensive systems models for MBSE, and use of these rich models for real-time operations. The paper describes a software platform that enables creation of comprehensive models, beyond what is now possible with SysML and related software tools, called the NASA Platform for Autonomous Systems (NPAS). The platform encapsulates a paradigm and infrastructure for creating systems models with complexity levels comparable to the ones handled by SysML software tools, but with additional fidelity that includes detailed design diagrams encompassing sensors, components, and design topologies. Furthermore, NPAS enables incorporation of data, information, and knowledge (DIaK) to implement autonomy and Integrated System Health Management (ISHM) and the inherent integration of content encompassing SysML structure and behavior diagrams throughout the NPAS modelAnd lastly, the NPAS models are used in real-time operations, taking advantage of the fidelity and complexity encompassed in the models in order to implement “thinking” ISHM and/or autonomous operations. . Incorporation of SysML model content into an NPAS model is briefly discussed.

MBSE↗
NASA NTRS2016

Graphical Acoustic Liner Design and Analysis Tool

An interactive liner design and impedance modeling tool comprises software utilized to design acoustic liners for use in constrained spaces, both regularly and irregularly shaped. A graphical user interface allows the acoustic channel geometry to be drawn in a liner volume while the surface impedance calculations are updated and displayed in real-time. A one-dimensional transmission line model may be used as the basis for the impedance calculations.

Howerton, Brian M.↗
NASA NTRS2001

Designing Control System Application Software for Change

The Unified Modeling Language (UML) was used to design the Environmental Systems Test Stand (ESTS) control system software. The UML was chosen for its ability to facilitate a clear dialog between software designer and customer, from which requirements are discovered and documented in a manner which transposes directly to program objects. Applying the UML to control system software design has resulted in a baseline set of documents from which change and effort of that change can be accurately measured. As the Environmental Systems Test Stand evolves, accurate estimates of the time and effort required to change the control system software will be made. Accurate quantification of the cost of software change can be before implementation, improving schedule and budget accuracy.

Boulanger, Richard↗
NASA NTRS1998

An Introduction to Markov Modeling: Concepts and Uses

Kharkov modeling is a modeling technique that is widely useful for dependability analysis of complex fault tolerant systems. It is very flexible in the type of systems and system behavior it can model. It is not, however, the most appropriate modeling technique for every modeling situation. The first task in obtaining a reliability or availability estimate for a system is selecting which modeling technique is most appropriate to the situation at hand. A person performing a dependability analysis must confront the question: is Kharkov modeling most appropriate to the system under consideration, or should another technique be used instead? The need to answer this gives rise to other more basic questions regarding Kharkov modeling: what are the capabilities and limitations of Kharkov modeling as a modeling technique? How does it relate to other modeling techniques? What kind of system behavior can it model? What kinds of software tools are available for performing dependability analyses with Kharkov modeling techniques? These questions and others will be addressed in this tutorial.

Boyd, Mark A.↗
NASA NTRS2007

Micromechanics of Spray-On Foam Insulation

Understanding the thermo-mechanical response of the Space Shuttle External Tank spray-on foam insulation (SOFI) material is critical, to NASA's Return to Flight effort. This closed-cell rigid polymeric foam is used to insulate the metallic Space Shuttle External Tank, which is at cryogenic temperatures immediately prior to and during lift off. The shedding of the SOFI during ascent led to the loss of the Columbia, and eliminating/minimizing foam lass from the tank has become a priority for NASA as it seeks to resume scheduled space shuttle missions. Determining the nature of the SOFI material behavior in response to both thermal and mechanical loading plays an important role as any structural modeling of the shedding phenomenon k predicated on knowledge of the constitutive behavior of the foam. In this paper, the SOFI material has been analyzed using the High-Fidelity Generalized Method of Cells (HFGMC) micromechanics model, which has recently been extended to admit a triply-periodic 3-D repeating unit cell (RUC). Additional theoretical extensions that mere made in order to enable modeling of the closed-cell-foam material include the ability to represent internal boundaries within the RUC (to simulated internal pores) and the ability to impose an internal pressure within the simulated pores. This latter extension is crucial as two sources contribute to significant internal pressure changes within the SOFI pores. First, gas trapped in the pores during the spray process will expand or contract due to temperature changes. Second, the pore pressure will increase due to outgassing of water and other species present in the foam skeleton polymer material. With HFGMC's new pore pressure modeling capabilities, a nonlinear pressure change within the simulated pore can be imposed that accounts for both of these sources, in addition to stmdar&-thermal and mechanical loading; The triply-periodic HFGMC micromechanics model described above was implemented within NASA GRC's MAC/GMC software package, giving the model access to a range of nonlinear constitutive models for the polymeric foam skeleton material. A repeating unit cell architecture was constructed that, while relatively simple, still accounts for the geometric anisotropy of the porous foam microstructure and its thin walls and thicker edges. With the lack of reliable polymeric foam skeleton materia1 properties, many simulations were executed aimed at backing out these material properties. Then, using these properties, predictions of the thermo-mechanical behavior of the foam, including calculated internal applied pressure profiles, were performed and compared with appropriate experimental data.

Bednarcyk, Brett A.↗
NASA NTRS2008

Execution-error modeling and analysis of the Cassini-Huygens spacecraft through 2007

The Cassini-Huygens spacecraft arrived at Saturn in 2004, beginning a four-year tour. Much of mission’s continued success at Saturn can be attributed to the excellent performance of the propulsion systems and attitude control. In order to better understand this performance, the Cassini Navigation Team has continued to analyze and refine the execution-error models for the propulsion systems. This paper documents the evolution of the execution-error models employed for maneuvers, along with the analysis, procedures, and software associated with the model development.

Goodson, Troy D.↗
NASA NTRS1993

SIMSAT: An object oriented architecture for real-time satellite simulation

Real-time satellite simulators are vital tools in the support of satellite missions. They are used in the testing of ground control systems, the training of operators, the validation of operational procedures, and the development of contingency plans. The simulators must provide high-fidelity modeling of the satellite, which requires detailed system information, much of which is not available until relatively near launch. The short time-scales and resulting high productivity required of such simulator developments culminates in the need for a reusable infrastructure which can be used as a basis for each simulator. This paper describes a major new simulation infrastructure package, the Software Infrastructure for Modelling Satellites (SIMSAT). It outlines the object oriented design methodology used, describes the resulting design, and discusses the advantages and disadvantages experienced in applying the methodology.

Williams, Adam P.↗
NASA NTRS2014

Towards Test Driven Development for Computational Science with pFUnit

Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.

pFUnit↗
NASA NTRS1992

An improved approach for flight readiness certification: Methodology for failure risk assessment and application examples. Volume 2: Software documentation

An improved methodology for quantitatively evaluating failure risk of spaceflight systems to assess flight readiness and identify risk control measures is presented. This methodology, called Probabilistic Failure Assessment (PFA), combines operating experience from tests and flights with engineering analysis to estimate failure risk. The PFA methodology is of particular value when information on which to base an assessment of failure risk, including test experience and knowledge of parameters used in engineering analyses of failure phenomena, is expensive or difficult to acquire. The PFA methodology is a prescribed statistical structure in which engineering analysis models that characterize failure phenomena are used conjointly with uncertainties about analysis parameters and/or modeling accuracy to estimate failure probability distributions for specific failure modes, These distributions can then be modified, by means of statistical procedures of the PFA methodology, to reflect any test or flight experience. Conventional engineering analysis models currently employed for design of failure prediction are used in this methodology. The PFA methodology is described and examples of its application are presented. Conventional approaches to failure risk evaluation for spaceflight systems are discussed, and the rationale for the approach taken in the PFA methodology is presented. The statistical methods, engineering models, and computer software used in fatigue failure mode applications are thoroughly documented.

Moore, N. R.↗
NASA NTRS2018

Considerations When Building Thermal Models that Require Conversion Between Formats

At times, it is inevitable to require conversion of thermal models from one software format to another. This most often occurs for missions with international partners where not all parties utilize the same software packages for thermal analysis. Mandating a single tool for all parties is one possible solution, but this approach can introduce problems if significant effort is required to overcome inexperience with the designated tool and may result in difficulty meeting analysis schedule requirements. Alternatively, allowing all parties to use their own familiar tools minimizes the impact to analysis schedules but does introduce the need to convert the models later to a common format for analysis at a higher level of assembly. External conversion tools and formats have been developed through the years to aid in this process, but have had limited success in fully converting models seamlessly. Having a basic familiarity with tool capabilities on both sides of the conversion process allows for models to be built in a manner to better facilitate conversion by avoiding features and capabilities which are unsupported by the destination tool or for which no workarounds exist. Also, the effort to convert a model is often neglected when developing the schedules for analysis at the higher assembly levels; delivery of models preconditioned for convertibility minimizes the schedule risk. This paper seeks to provide some guidance on modeling techniques to avoid when developing Geometrical Math Models (GMM) and Thermal Math Models (TMM) when conversion is required. The recommendations are based on GMM conversion experiences between TSS/ThermalDesktop/ESARAD and TMM conversions between SINDA-FLUINT/ESATAN.

Modeling↗
NASA NTRS1993

Human Factors Model

Jack is an advanced human factors software package that provides a three dimensional model for predicting how a human will interact with a given system or environment. It can be used for a broad range of computer-aided design applications. Jack was developed by the computer Graphics Research Laboratory of the University of Pennsylvania with assistance from NASA's Johnson Space Center, Ames Research Center and the Army. It is the University's first commercial product. Jack is still used for academic purposes at the University of Pennsylvania. Commercial rights were given to Transom Technologies, Inc.

Source record↗
NASA NTRS2001

Lyapunov-Based Sensor Failure Detection And Recovery For The Reverse Water Gas Shift Process

Livingstone, a model-based AI software system, is planned for use in the autonomous fault diagnosis, reconfiguration, and control of the oxygen-producing reverse water gas shift (RWGS) process test-bed located in the Applied Chemistry Laboratory at KSC. In this report the RWGS process is first briefly described and an overview of Livingstone is given. Next, a Lyapunov-based approach for detecting and recovering from sensor failures, differing significantly from that used by Livingstone, is presented. In this new method, models used are in terms of the defining differential equations of system components, thus differing from the qualitative, static models used by Livingstone. An easily computed scalar inequality constraint, expressed in terms of sensed system variables, is used to determine the existence of sensor failures. In the event of sensor failure, an observer/estimator is used for determining which sensors have failed. The theory underlying the new approach is developed. Finally, a recommendation is made to use the Lyapunov-based approach to complement the capability of Livingstone and to use this combination in the RWGS process.

Haralambous, Michael G.↗