SEARCH · Search NASA

Results for “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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 811 records · Page 45

All sources NASA NTRS DOE OSTI

NASA NTRS2004

Autonomy software verification and validation might not be as hard as it seems

The verification and validation of autonomy software is widely believed to be a challenging unsolved problem. To a certain extent this is true, but in this paper I argue that the problem is not nearly as severe as seems to be widely perceived. many of the perceived hard problems in autonomy software V&V also exist for traditional software, and can be solved using many of the same methods and techniques used for traditional spacecraft software. In particular, the problem of intractably large state spaces exists for any non-trivial software system.

Gat, Erann↗

NASA NTRS2009

Earned Value Management Software Projects

JPL has been attempting to apply EVM techniques for the last 15 years with mixed success, especially when applied to software tasks. One of the main causes is that software presents particular challenges that were not considered during the genesis of EVM. A small number of tasks have been able to use EVM effectively and derive great benefits. This paper discusses challenges specific to software management and how they can be successfully addressed. Specifically, it details lessons learned from the $28 million dollar Next Generation Navigation Software Project that replaced NASA’s deep space navigation software for operations. The project was able to successfully use EVM techniques during a four year period, producing 12 releases on their promised delivery dates and projects actual costs that were within 0.3% of the planned budget (under), in contrast to performance before the techniques were put into practice.

Hanna, Robert A.↗

NASA NTRS2021

Vertiport Automation Software Architecture and Requirements

The purpose of Vertiport Automation Software Architecture and Requirements was developed to mature the Vertiport Automation System (VAS) described in the High-Density Automated Vertiport ConOps, into a set of artifacts that enable the development of a VAS prototype. The scope of document was to develop: (1) A VAS Software Architecture diagram that logically organizes VAS functionality into specific software components; (2) VAS Software Trade Study identifying existing commercial products and NASA research that can be used in part or with modifications to fulfill VAS functionality. (3) A set of VAS Functional Requirements which decompose the VAS concept into software functionality, including any interfaces and data flows needed; (4) A set of VAS Test Approaches describing a methodology for verification of the VAS Functional Requirements; and (5) An application user experience (UX) design study describing the general features needed in a VAS user interface.

Advanced Air Mobility↗

NASA NTRSDate not supplied

An Integrated Software Architecture for Solar Cruiser Mission Design and Navigation

Solar Cruiser is a solar sailing mission, riding as a secondary payload to the Interstellar Mapping and Acceleration Probe (IMAP) mission, expected to launch in February of 2025. The Solar Cruiser vehicle will generate thrust via a complex, low-thrust solar sail. The extreme low-thrust nature of the solar sail will leave Solar Cruiser highly sensitive to external environmental effects (such as solar radiation pressure and high-order gravitational perturbations) throughout the entirety of flight. Because of this, preliminary & operational optimization routines must be intricately tied to high-order predictive propagation models to ensure the greatest possible confidence in mission success. The Solar Cruiser Mission Design and Navigation (MDNav) team has designed a software tool suite, employing the latest in software containerization technology, to accomplish this task, allowing for seamless development across several users and operating systems. Combining JPL’s Monte toolkit with high-performance optimizers written by researchers at the University of Alabama, the proposed architecture allows for instant verification of optimized trajectories within the same development environment that the optimization takes place, removing the need for mission designers and navigators to switch between tools. The MDNav software suite itself is separated from the development and operational scripts to be used in flight, which allows for maintaining a low-footprint version control profile – thus avoiding unnecessary file bloating. This paper discusses the historical differences between previous iterations of the Solar Cruiser MDNav tool suite and the current iteration, planned operational interfaces of the tool with other software and subsystems, and the planned path forward in maintaining containerization services for the software throughout the lifetime of Solar Cruiser.

Containerization↗

NASA NTRS2021

Trust in Collaborative Automation in High Stakes Software Engineering Work

The amount of autonomy in software engineering tools is increasing as developers build increasingly complex systems. Research in other domains shows that too much or too little trust in autonomous tools can have negative consequences, but we are not aware of any study that has investigated trust in autonomous tools in the highly interactive context of a software engineering workplace. We present the results of a ten week ethnographic case study of engineers collaborating with autonomous tools to write flight software at a large national space exploration organization to support high stakes missions. We find that trust in an autonomous software engineering tool in this setting was influenced by four main factors: the tool’s transparency, social context, an organization’s associated processes, and its usability. We outline theoretical implications for future research into trust in autonomous software engineering tools, and practical implications for tool designers and organizations conducting high stakes work with autonomous tools.

Davidoff, Scott↗

NASA NTRSDate not supplied

Orion Backup Flight Software

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

Orion↗

NASA NTRSDate not supplied

Orion Backup Flight Software (BFS)

CFS↗

NASA NTRSDate not supplied

The Anatomy of Software Changes and Bugs in Autonomous Operating System

Cyberphysical systems with autonomous functions are complex pieces of software, consisting of many components, some of which implement autonomous functionality and some may use AI or machine learning algorithms. Software bugs in an autonomous system are of particular concern, as they can have catastrophic consequences. However, detailed studies based on empirical data are rare and therefore these bugs are not well understood. This paper aims to contribute towards filling that gap by investigating the software changes and bugs in Autonomy Operating System (AOS) for Unmanned Aircraft Systems (UAS), which consist of 26 components containing about 103,000 lines of code and having a total of 772 bugfixes. Based on the data extracted from the code repository and semi-structured interviews with the developers of AOS, we explore the differences among autonomous software components, components developed using Model-based Software Engineering, and reuse with respect to change proneness, fault proneness, distribution of bugfixes among AOS components and files of these components, and characteristics of bugs of different AOS components. Our results show that the autonomous components were significantly more change prone (measured in number of commits and code churn) and fault prone (measured in bugfixes per KLoC) than non-autonomous components. The distribution of the locations of bugfixes was skewed, both at component and file level (i.e., a small number of components / files contained the majority of bugs). These evidence-based findings provide important insights to researchers and practitioners alike and can be used to efficiently improve the quality and reliability of autonomous systems.

Katerina Goseva-Popstojanova↗

NASA NTRSDate not supplied

Autonomous Robotic Manipulator Software

Autonomous robotic manipulation requires a deep and wide stack of supporting software. This paper presents Autonomous Robotic Manipulator Software (ARMS), a software suite designed at NASA Langley Research Center to support research and development of different algorithms for In-space Servicing, Assembly and Manufacturing (ISAM). ARMS solves common challenges along the autonomous manipulation software stack. Various challenges, such as integration with commercial hardware, simulation, and path planning, are solved through the use of Robot Operating System 2 and its community-developed packages. Other challenges, such as configuration management and task definition, and execution are solved in software built on those tools. The result is a modular approach to robotic system definition, agent actions, and assembly task definitions. ARMS has been used in two ISAM projects at NASA Langley Research Center, the Precision Assembled Space Structures project and the Built On-orbit Robotically assembled Gigatruss project.

Collin J Cresta↗

NASA NTRSDate not supplied

Autonomous Robotic Manipulator Software (ARMS)

Collin J Cresta↗

NASA NTRSDate not supplied

CEA2022: A Modernization of NASA Glenn’s Software CEA (Chemical Equilibrium with Applications)

The software program “Chemical Equilibrium with Applications” (CEA) is used to solve chemical equilibrium, and compute thermodynamic and transport properties of the resulting mixture, and also has special solvers dedicated to rocket, shock, and detonation problems. We have recently completed a full re-write of CEA with modernization and improvements, called “CEA2022”. In this paper, we will give an overview of CEA2022’s features, and discuss some of the fundamental equations used by CEA2022, as well as the fundamental assumptions, in order to provide users with a complete understanding of the software’s methodology. Several enhancements have been made to the software, including modern software development practices, interface improvements, and additional features. The feature enhancements include: running cases in parallel with thread safe solves, thermodynamic and transport database updates, and allowing for negative and inert reactants. In terms of interface improvements, we have made CEA a reusable library by adding APIs for multiple languages, including Python, Matlab, Excel, Fortran, and C. The subroutine interface allows for integration with other applications, including flow-solver integration (i.e. with CFD). We also compare results between CEA2022 and the previous version (CEA2) as a validation of the new software.

chemical equilibrium↗

DOE OSTI2019

Development of an Automated J-R Curve Analysis Software Based on the ASTM E1820-18 Normalization Method

The J-integral versus crack-growth resistance curve (J-R curve) is a useful tool for evaluating material fracture toughness in the ductile region. A widely accepted practice for conducting J-R curve testing is ASTM standard E1820, which introduces the normalization method. This method does not require compliance measurements during testing, significantly simplifying J-R curve testing compared with the conventional elastic unloading compliance (EUC) method. Despite the advantage in testing, analysis procedures for the normalization method are very complicated. Also, there is no open source software currently available to perform such analysis.The authors developed an open source automated J-R curve-analysis software based on the normalization method in ASTM E1820-18. Source codes were written in MATLAB and the compiled software, in the form of a stand-alone executable, has a user-friendly graphic interface and is readily compatible with modern Windows operating systems. Both source codes and the compiled executable file are available for download at https://code.ornl.gov/xc8/ANJR.git. Comparisons between resulting J-R curves from the software and manual analysis procedures show essentially identical results, indicating the suitability of applying the automated software for J-R curve analysis.

36 MATERIALS SCIENCE↗

DOE OSTI2020

Process Heating Assessments Using DOE’s Manufacturing Energy Assessment Software for Utility Reduction (MEASUR) Tool Suite

Process heating is the most energy-intensive manufacturing process for most sectors of industry. To quantify energy savings from various energy conservation measures, the Department of Energy (DOE) sponsored the development of the Process Heating Assessment and Survey Tool (PHAST) and similar tools for other industrial systems in the early 2000s. It has been used extensively in the Save Energy Now Program’s Energy Savings Assessments and the Better Plants Program’s In-Plant Trainings. Since the initial development of the legacy tools, both computer operating systems and software development have evolved significantly. Thus, DOE has invested in the modernization of PHAST and other legacy software tools to create the Manufacturing Energy Assessment Software for Utility Reduction (MEASUR) tool suite. MEASUR offers a collection of software tools that can aid manufacturing facilities in improving the efficiency of energy systems and equipment (specifically pumps, fans, steam, and process heating) and in conducting “Energy Treasure Hunts”. Eventually, the tool will also add compressed air and process cooling systems. The Process Heating Assessment (PHA) module of MEASUR is an upgrade of the PHAST tool. PHA provides the means to model fuel-fired, steam-based, and electric process heating systems, covering process heating for most industrial plants in manufacturing sector. It also includes several key upgrades, including the ability to consider multi-component charge loads and account for several different areas of energy losses. The new tool includes a comprehensive flue gas calculator to quantify available heat and heat loss for various gaseous, liquid, and solid fuels and new heat loss calculators. It generates a report and a dynamic Sankey diagram to show the energy consumption in various areas of energy use. MEASUR has significantly improved the user experience by adopting a modern software design. This paper details the structure and workflow of PHA and presents a real-world case study to demonstrate energy savings quantification and MEASUR’s outstanding reporting capabilities.

Nimbalkar, Sachin U.↗

DOE OSTI2021

Containerization in ATLAS Software Development and Data Production

The ATLAS experiment's software production and distribution on the grid benefits from a semi-automated infrastructure that provides up-to-date information about software usability and availability through the CVMFS dis-tribution service for all relevant systems. The software development process uses a Continuous Integration pipeline involving testing, validation, packag-ing and installation steps. For opportunistic sites that can not access CVMFS, containerized releases are needed. These standalone containers are currently created manually to support Monte-Carlo data production at such sites. In this paper we will describe an automated procedure for the containerization of AT-LAS software releases in the existing software development infrastructure, its motivation, integration and testing in the distributed computing system.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2023

Software Quality Assurance for High Performance Computing Containers

Software containers are a key channel for delivering portable and reproducible scientific software in high performance computing (HPC) environments. HPC environments are different from other types of computing environments primarily due to usage of the message passing interface (MPI) and drivers for specialized hard- ware to enable distributed computing capabilities. This distinction directly impacts how software containers are built for HPC applications and can complicate software quality assurance efforts including portability and performance. This work introduces a strategy for building containers for HPC applications that adopts layering as a mechanism for software quality assurance. The strategy is demonstrated across three different HPC systems, two of them petaflops scale with entirely different interconnect technologies and/or processor chipsets but running the same container. Performance consequences of the containerization strategy are found to be less than 5-14% while still achieving portable and reproducible containers for HPC systems.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2024

Techniques for recovering from errors when executing software applications on parallel processors

In various embodiments, a software program uses hardware features of a parallel processor to checkpoint a context associated with an execution of a software application on the parallel processor. The software program uses a preemption feature of the parallel processor to cause the parallel processor to stop executing instructions in accordance with the context. The software program then causes the parallel processor to collect state data associated with the context. After generating a checkpoint based on the state data, the software program causes the parallel processor to resume executing instructions in accordance with the context.

Hukerikar, Saurabh↗

DOE OSTI2024

Software-Defined Virtual Synchronous Condenser

Synchronous condensers (SCs) play important roles in integrating wind energy into relatively weak power grids. However, the design of SCs usually depends on specific application requirements and may not be adaptive enough to the frequently-changing grid conditions caused by the transition from conventional to renewable power generation. This paper devises a software-defined virtual synchronous condenser (SDViSC) method to address the challenges. Our contributions are fourfold: 1) design of a virtual synchronous condenser (ViSC) to enable full converter wind turbines to provide built-in SC functionalities; 2) engineering SDViSCs to transfer hardware-based ViSC controllers into software services, where a Tustin transformation-based software-defined control algorithm guarantees accurate tracking of fast dynamics under limited communication bandwidth; 3) a software-defined networking-enhanced SDViSC communication scheme to allow enhanced communication reliability and reduced communication bandwidth occupation; and 4) Prototype of SDViSC on our real-time, cyber-in-the-loop digital twin of large-wind-farm in an RTDS environment. Furthermore, extensive test results validate the excellent performance of SDViSC to support reliable and resilient operations of wind farms under various physical and cyber conditions.

17 WIND ENERGY↗

DOE OSTI2018

Defining and Characterizing Methods, Tools, and Computing Resources to Support Pseudo Exhaustive Testability of Software Based I&C Devices

Under the Department of Energy’s Light Water Reactor Sustainability Program, within the Plant Modernization research pathway, the Digital I&C Qualification Project is identifying new methods that would be beneficial in qualifying digital I&C systems and devices for safety-related usage. One such method that would be useful in qualifying field components such as sensors and actuators is the concept of testability. The Nuclear Regulatory Commission (NRC) considers testability to be one of two design attributes sufficient to eliminate consideration of software-based or software logic-based common cause failure (the other being diversity). The NRC defines acceptable “testability” as follows: Testability – A system is sufficiently simple such that every possible combination of inputs and every possible sequence of device states are tested and all outputs are verified for every case (100% tested). [NUREG 0800, Chapter 7, Branch Technical Position (BTP) 7-19] This qualification method has never proven to be practical in view of the very large number of combinations of inputs and sequences of device states for a typical I&C device. However, many of these combinations are not unique in the sense that they represent the same state space or in that that they represent state space that would not affect the critical design basis functions of the device. Therefore, the state space of interest might possibly be reduced to a manageable dimension through such analysis. This project focuses on a representative I&C device similar in design, function, and complexity to the types of devices that would likely be deployed in nuclear power plants as digital or software based sensors and actuators (e.g. Smart Sensors). Analysis will be conducted to determine the feasibility of testing this device in a manner consistent with the NRC definition. This report describes acceptable test methods, needed tools (existing or new), and computing resources, all based on engineering and computer science principles. This information will then be used in a later phase of this project to develop a test specification for I&C device testability that can be used in a future phase of this project to demonstrate digital qualification with respect to common cause failure. Following that, testing will be conducted and the results analyzed to determine if the methods employed are sufficient to eliminate consideration of software common cause failure in accordance with the concept of testability.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗