Search NASA⌕ Search

SEARCH · Search NASA

Results for “software performance”

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 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

An experimental investigation of fault tolerant software structures in an avionics application

The objective of this experimental investigation is to compare the functional performance and software reliability of competing fault tolerant software structures utilizing software diversity. In this experiment, three versions of the redundancy management software for a skewed sensor array have been developed using three diverse failure detection and isolation algorithms and incorporated into various N-version, recovery block and hybrid software structures. The empirical results show that, for maximum functional performance improvement in the selected application domain, the results of diverse algorithms should be voted before being processed by multiple versions without enforced diversity. Results also suggest that when the reliability gain with an N-version structure is modest, recovery block structures are more feasible since higher reliability can be obtained using an acceptance check with a modest reliability.

Caglayan, Alper K.↗
NASA NTRS1994

A proven approach for more effective software development and maintenance

Modern space flight mission operations and associated ground data systems are increasingly dependent upon reliable, quality software. Critical functions such as command load preparation, health and status monitoring, communications link scheduling and conflict resolution, and transparent gateway protocol conversion are routinely performed by software. Given budget constraints and the ever increasing capabilities of processor technology, the next generation of control centers and data systems will be even more dependent upon software across all aspects of performance. A key challenge now is to implement improved engineering, management, and assurance processes for the development and maintenance of that software; processes that cost less, yield higher quality products, and that self-correct for continual improvement evolution. The NASA Goddard Space Flight Center has a unique experience base that can be readily tapped to help solve the software challenge. Over the past eighteen years, the Software Engineering Laboratory within the code 500 Flight Dynamics Division has evolved a software development and maintenance methodology that accommodates the unique characteristics of an organization while optimizing and continually improving the organization's software capabilities. This methodology relies upon measurement, analysis, and feedback much analogous to that of control loop systems. It is an approach with a time-tested track record proven through repeated applications across a broad range of operational software development and maintenance projects. This paper describes the software improvement methodology employed by the Software Engineering Laboratory, and how it has been exploited within the Flight Dynamics Division with GSFC Code 500. Examples of specific improvement in the software itself and its processes are presented to illustrate the effectiveness of the methodology. Finally, the initial findings are given when this methodology was applied across the mission operations and ground data systems software domains throughout Code 500.

Pajerski, Rose↗
NASA NTRS1976

Space shuttle orbital maneuvering system failure detection and identification software requirements (uncontrolled)

Candidate designs and their software implementation are presented for the Orbital Maneuvering System (OMS) Failure Detection and Identification (FDI) algorithms in the Redundance Management (RM) module of the Space Shuttle Guidance, Navigation, and Control (GN&C) software. The OMS engine FDI algorithm monitors OMS engine thrust performance, and the OMS actuator FDI algorithm monitors OMS gimbal actuator performance. The software functional requirements of the algorithms are described along with the objective of each algorithm. A list of the assumptions which have governed its design, input/output requirements, a functional description of the algorithm (including a functional block diagram), and input interface requirements are given. The HAL (the language of the space shuttle flight computer) software formulation of the algorithms is considered including structured flowcharts of the procedures, estimates of flight computer core storage and CPU time, and processing requirements. A glossary of the symbols used to define the software requirements and formulations is included.

Damario, L. A.↗
NASA NTRS1991

Statistical modelling of software reliability

During the six-month period from 1 April 1991 to 30 September 1991 the following research papers in statistical modeling of software reliability appeared: (1) A Nonparametric Software Reliability Growth Model; (2) On the Use and the Performance of Software Reliability Growth Models; (3) Research and Development Issues in Software Reliability Engineering; (4) Special Issues on Software; and (5) Software Reliability and Safety.

Miller, Douglas R.↗
DOE OSTI2023

Automated tracking of prefabricated components for areal-time evaluator to optimize and automateinstallation

Trade associations for prefabricated construction estimate that about 50% of prefabricated wall projects have alignment problems that lead to defects and rework. Additionally, component installation times average between 30 and 60 minutes per component. To address these issues, a real-time evaluator (RTE) system was introduced to decrease cost and automate prefabricated component installation by reducing the installation time, decreasing rework, and enhancing energy performance through higher installation quality. The RTE uses commonly available hardware and software to perform autonomous tracking to measure the real-time location and orientation of components as they are crane-lifted and installed. The hardware, software, and algorithms that allow the autonomous tracking of components are detailed. An algorithm to automate the initial search for a component with three attached retroreflectors is proposed. Algorithms to automate the measurement of component position and orientation are also proposed. Simple lab-scale proof-of-concept experiments were conducted to assess the algorithms for automation of component searching, measurement of real-time movement, and measurement of component orientation. With additional development, the system can be used as a tool to generate the commands for autonomous crane operation or single-task construction robots.

Hayes, Nolan↗
NASA NTRS1985

Automation of checkout for the shuttle operations era

The Space Shuttle checkout is different from its Apollo predecessor. The complexity of the hardware, the shortened turnaround time, and the software that performs ground checkout are outlined. Generating new techniques and standards for software development and the management structure to control it are implemented. The utilization of computer systems for vehicle testing is high lighted.

Anderson, J. A.↗
NASA NTRS1985

Software life cycle dynamic simulation model: The organizational performance submodel

The submodel structure of a software life cycle dynamic simulation model is described. The software process is divided into seven phases, each with product, staff, and funding flows. The model is subdivided into an organizational response submodel, a management submodel, a management influence interface, and a model analyst interface. The concentration here is on the organizational response model, which simulates the performance characteristics of a software development subject to external and internal influences. These influences emanate from two sources: the model analyst interface, which configures the model to simulate the response of an implementing organization subject to its own internal influences, and the management submodel that exerts external dynamic control over the production process. A complete characterization is given of the organizational response submodel in the form of parameterized differential equations governing product, staffing, and funding levels. The parameter values and functions are allocated to the two interfaces.

Tausworthe, Robert C.↗
DOE OSTI2021

Toward performance-portable PETSc for GPU-based exascale systems

The Portable Extensible Toolkit for Scientific computation (PETSc) library delivers scalable solvers for nonlinear time-dependent differential and algebraic equations and for numerical optimization. The PETSc design for performance portability addresses fundamental GPU accelerator challenges and stresses flexibility and extensibility by separating the programming model used by the application from that used by the library, and it enables application developers to use their preferred programming model, such as Kokkos, RAJA, SYCL, HIP, CUDA, or OpenCL, on upcoming exascale systems. Furthermore, a blueprint for using GPUs from PETSc-based codes is provided, and case studies emphasize the flexibility and high performance achieved on current GPU-based systems.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Defining a compact dry cooler design to reduce LCOE contribution in a CSP facility

Concentrating solar power (CSP), when coupled with a supercritical carbon dioxide (sCO 2 ) power cycle and sensible heat storage, presents a renewable and clean alternative for utility-scale power generation. However, in order to be competitive in the current and future markets, CSP facilities must limit their levelized cost of electricity (LCOE) by minimizing capital costs and reducing operating costs over the lifetime of the plant. Targeting this goal, this study investigates the LCOE impact of the power cycle pre-cooler. This study considers a compact dry cooler with micro-channel technology on the CO 2 side and formed fin geometry on the air side, using directly-coupled centrifugal fans and a transition duct to improve air distribution across the fins as well as protect the fins from contaminants which may cause blockage, soiling, fouling, and damage. In an effort to better understand the dry cooler impact on LCOE, a sensitivity study was conducted using various combinations of end-to-end approach temperatures, air-side pressure drop values, CO 2 -side pressure drop values, fan types, cooler turndown control schemes, cooler module sizes, and design-point ambient temperatures. Furthemore, off-design cycle performance data was calculated for each dry cooler design using NPSS simulation software; cycle performance data were then input to System Advisor Model (SAM) along with the associated capital costs for LCOE prediction of a 100 MW system over a 30 year plant lifetime. Results of this study show the LCOE is most sensitive to air-side performance, followed by heat transfer effectiveness and capital cost. It was found that a power cycle with a mid- to high-performance dry cooler will produce the most competitive power-production costs. Designing at the extreme ends for approach temperature (or effectiveness), design-point ambient temperature, and compactness (footprint) produce higher LCOE values; mid-range values for these parameters balance performance, operating costs, and associated capital cost to optimize LCOE.

14 SOLAR ENERGY↗
NASA NTRS2007

Development of a Prototype Automation Simulation Scenario Generator for Air Traffic Management Software Simulations

A technique for automated development of scenarios for use in the Multi-Center Traffic Management Advisor (McTMA) software simulations is described. The resulting software is designed and implemented to automate the generation of simulation scenarios with the intent of reducing the time it currently takes using an observational approach. The software program is effective in achieving this goal. The scenarios created for use in the McTMA simulations are based on data taken from data files from the McTMA system, and were manually edited before incorporation into the simulations to ensure accuracy. Despite the software s overall favorable performance, several key software issues are identified. Proposed solutions to these issues are discussed. Future enhancements to the scenario generator software may address the limitations identified in this paper.

Khambatta, Cyrus F.↗
NASA NTRS2020

Blackbird: Object-Oriented Planning, Simulation, and Sequencing Framework Used by Multiple Missions

Every JPL flight mission relies on activity planningand sequence generation software to perform operations. Mostsuch tools in use at JPL and elsewhere use attribute-basedschemas or domain-specific languages (DSLs) to defineactivities. This reliance poses user training, softwaremaintenance, performance, and other challenges. To solve thisproblem for future missions, a new software called Blackbirdwas developed which allows engineers to specify behavior instandard Java. The new code base has over an order ofmagnitude fewer lines of code than other JPL planningsoftware, since no DSL or schema interpreter is needed. Theuse of Java for defining activities also allows mission adaptersto debug their code in an integrated development environment,seamlessly call external libraries, and set up truly multimissionmodels. These efficiency gains have significantlyreduced the amount of development effort required to supportthe software. This paper discusses Blackbird’s design,principles, and use cases.

Rothstein-Dowden, Ansel↗
NASA NTRS1993

A quick uplink, expandable executable for the NSSC-1 of the Hubble Space Telescope

The Hubble Space Telescope, launched in April 1990, contains two primary on-board computers. In the past, modifications to the flight software have been accomplished via patches to the on-board executable image (performed while software is executing) or via halt and reload of the computer memory with a new flight software version. This paper describes a method of reloading flight software with a new software version while continuing the onboard execution of a reduced set of spacecraft payload functions.

Foley, Glenn T.↗
DOE OSTI2021

Uncertainty Analysis and Software Verification

Uncertainty analyses are an important part of calibrations and testing. They allow researchers insight on how to reduce and mitigate errors in testing. Each device used in testing introduces error in a system, as well as other sources such as environmental conditions, electronics, analog to digital, and random errors. Each source is carefully examined to identify how much error it introduces to a system. These sources are then combined using various methods of uncertainty calculations. To verify and validate software, a manual calculation is required to ensure the software is performing as intended. Using Excel to verify the calculations, we can identify discrepancies within the software. The root of the sum of the squares uncertainty (RSS) is used to find the combined uncertainty of a device at one and two standard deviations of the mean. Calibrations on accelerometers are performed using a vibration system along with a back-toback reference accelerometer. The vibration system takes a reference point at 100Hz frequency at 10g amplitude. The sensitivities are collected at each dialed in frequency. The sensitivity of the device represents the electrical output of the UUT (mV, pC, etc.) per unit of acceleration (g). The full history of sensitivities of selected accelerometers are used to find the averaged, standard deviation, and uncertainty of the device at each frequency tested. The uncertainty calculations from excel and the software are then compared.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

M-Star ® Software Test and Verification

Savannah River Mission Completion (SRMC) currently manages the risk for retained hydrogen in the Defense Waste Processing Facility (DWPF) vessels by implementing a Retained Hydrogen Program. The current program relies on Sludge Batch (SB) 8 Gas Chromatograph data and on conservative assumptions concerning gas release and retention to determine allowable vessel Quiescent time (Q-time). The authors identified M-Star ® CFD as a software that could simulate processes such as fluid flow, heat transfer, species transport, chemical reactions, particle transport, and retained hydrogen gas release. Preliminary simulation results suggest that more realistic assumptions on gas retention and release may be feasible for the DWPF retained hydrogen program. Because of the desire to use the M-Star ® software to perform analyses that support nuclear safety, SRMC has requested Savannah River National Laboratory (SRNL) to upgrade the software classification level of M-Star ® CFD from level D to level A to perform analyses that support nuclear safety.

08 HYDROGEN↗
NASA NTRS1985

A comparison of software verification techniques

A controlled experiment performed by the Software Engineering Laboratory (SEL) to compare the effectiveness of code reading, functional testing, and structural testing as software verification techniques is described. The experiment results indicate that code reading provides the greatest error detection capability at the lowest cost, whereas structural testing is the least effective technique. The experiment plan is explained, the experiment results are described, related results from other studies are discussed. The application of these results to the development of software in the flight dynamics environment is considered. Appendices summarize the experiment data and list the test programs.

Source record↗
NASA NTRS2008

Scripting Module for the Satellite Orbit Analysis Program (SOAP)

This add-on module to the SOAP software can perform changes to simulation objects based on the occurrence of specific conditions. This allows the software to encompass simulation response of scheduled or physical events. Users can manipulate objects in the simulation environment under programmatic control. Inputs to the scripting module are Actions, Conditions, and the Script. Actions are arbitrary modifications to constructs such as Platform Objects (i.e. satellites), Sensor Objects (representing instruments or communication links), or Analysis Objects (user-defined logical or numeric variables). Examples of actions include changes to a satellite orbit ( v), changing a sensor-pointing direction, and the manipulation of a numerical expression. Conditions represent the circumstances under which Actions are performed and can be couched in If-Then-Else logic, like performing v at specific times or adding to the spacecraft power only when it is being illuminated by the Sun. The SOAP script represents the entire set of conditions being considered over a specific time interval. The output of the scripting module is a series of events, which are changes to objects at specific times. As the SOAP simulation clock runs forward, the scheduled events are performed. If the user sets the clock back in time, the events within that interval are automatically undone. This script offers an interface for defining scripts where the user does not have to remember the vocabulary of various keywords. Actions can be captured by employing the same user interface that is used to define the objects themselves. Conditions can be set to invoke Actions by selecting them from pull-down lists. Users define the script by selecting from the pool of defined conditions. Many space systems have to react to arbitrary events that can occur from scheduling or from the environment. For example, an instrument may cease to draw power when the area that it is tasked to observe is not in view. The contingency of the planetary body blocking the line of sight is a condition upon which the power being drawn is set to zero. It remains at zero until the observation objective is again in view. Computing the total power drawn by the instrument over a period of days or weeks can now take such factors into consideration. What makes the architecture especially powerful is that the scripting module can look ahead and behind in simulation time, and this temporal versatility can be leveraged in displays such as x-y plots. For example, a plot of a satellite s altitude as a function of time can take changes to the orbit into account.

Carnright, Robert↗