SEARCH · Engineering Papers

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 775 records · Page 43

All sources NASA NTRS DOE OSTI

NASA NTRS2018

Hybridized Agile Software Development of Flight Control Team Tools for International Space Station's Payload Operations Integration Center

Ground systems operations at the National Aeronautics and Space Administration's (NASA) Payload Operations and Integration Center (POIC) at Marshall Space Flight Center (MSFC) recently increased via a High Operations Tempo (HOT) initiative, in order to support more science activities with a fourth crew member on the International Space Station (ISS). The Flight Control Team's (FCT) need to support this increasing pace of payload science operations was the impetus for creating a series of new tools. While their need was clear, the full scope and user experience for each tool was not as well-understood, thus establishing a fixed set of initial requirements was not feasible. A hybridized Agile Software Development (ASD) paradigm was created to take advantage of this uncertainty, plan for it, permit the exploration of novel concepts, and also facilitate a rapid and flexible response to inevitably changing requirements. The POIC's hybridized ASD approach places preeminent focus on providing customer value through the delivery of high quality, customer-focused solutions in short timeframes. This has been successfully achieved through creating unprecedented modes of cooperation and collaboration between operations and software development teams, frequent user evaluations of the software with well-defined feedback mechanisms, increased human factors involvement, and a dedication to successful outcomes by the whole of the POIC. Since space science operations and software development are not typically so closely linked, this paper discusses an approach that offers an optimal way to provide an increased return on investment and a faster time-to-completion than traditional software development paradigms, while aiming at delivering high quality products and customer-driven value.

Albers, Cerese M.↗

NASA NTRS2018

Command and Control Software Development

As NASA’s role in spaceflight operations change, so too does its design priorities. NASA’s flagship venture, the Space Launch System (SLS), is being created primarily to explore deep space. While commercial partners conduct low Earth orbit resupplies, tests, and even transportation of astronauts, NASA can divert more resources to more exciting projects - going back to the moon, or onwards to Mars. In the short term, this goal manifests in the upcoming Exploration Mission-1 (EM-1) test of the SLS, slated for as early as 2019. SLS, with the Orion capsule, will travel farther than any human-rated spacecraft has gone before. As the most powerful launch vehicle ever created, SLS requires many new innovations to ensure mission success. One such technology is the launch control software, which is the focus of this internship. The SLS launch control software is composed of many functions, all of which require rigorous testing to meet the standard of life-critical code. To facilitate easier testing, the first project I undertook was to customize the open-source tool Wireshark to the software team’s needs. Wireshark is a network protocol analyzer that can take in information about custom information packets. The launch control software will have several protocols that are custom to NASA. I ensured that all necessary component files were the correct file type and in the correct structure for Wireshark to compile. Having allowed Wireshark access to understand custom NASA data packets, testers of the launch control software will be able to find anomalies easier.

Wang, Zhengdong↗

NASA NTRS2019

Astrobee Robot Software: Enabling Mobile Autonomy on the ISS

Astrobee is a new free-flyer robot designed to operate inside the International Space Station (ISS). Astrobee capabilities include markerless navigation, autonomous docking for recharge, perching on handrails to minimize power and modular payloads. Astrobee will operate without crew support, controlled by teleoperation, plan execution, or on-board third parties software. This slides presents the Astrobee Robot Software, a NASA Open-Source project, powering the Astrobee robot.The Astrobee Robot Software relies on a distributed architecture based on the Robot Operating System (ROS). We present the software approach, infrastructure required, and main software components.

Fluckiger, Lorenzo↗

NASA NTRS2019

Software and System Health Management with R2U2

R2U2 (Realizable, Responsive, Unobtrusive Unit) is a hardware-supported tool and framework for the real-time system and software health management of cyber-physical systems. R2U2 continuously monitors properties about safety, performance, and security of the vehicle and can perform diagnostic reasoning. Efficient observers for past-time and future-time Metric Temporal Logic, reasoners for Bayesian Networks, and model-based prognostics algorithms are major components of R2U2. Their combination makes it possible to design powerful models for system runtime monitoring, diagnostics, software health management, prognostics, and security monitoring. The R2U2 monitoring engine is designed for minimal runtime overhead and is available as Simulink block or as a software component for integration into the flight software stack, and enables R2U2 to monitor complex cyber-physical systems without any instrumentation of the flight software. In this presentation, we give an overview of R2U2 architecture and reasoning algorithms, present its features, and give a life demo of the tool.

Schumann, Johann↗

NASA NTRS2003

Increasing software testability with standard access and control interfaces

Testing is the most common method of determining whether a software system satisfies its requirements. Traditionally, testing starts with the detailed examination of individual functions or methods, progresses through the integration of functions or methods into subsystems, and ends with testing the functionality and behavior of the completely integrated system. At each stage of testing, the amount of functionality and behavior of the artifact being tested is increasingly limited. One reason for this is that it becomes impossible to test all paths through the system within a reasonable amount of time. However, another reason for this progressive decrease of test coverage has to do with increasingly limited control of and visibility into the state of the artifact being tested. During unit test, it is rather simple to control the inputs of individual functions or methods or view their internal state - modem development environments provide adequate facilities for doing so. However, these facilities do not scale up to the testing of partially or completely integrated systems. Control of and visibility into the system's state is then limited to the input and output facilities provided by the software itself as well as the hardware on which the software is hosted during the test. These facilities are usually insufficient to precisely control the state of individual components or sets of components of the system; they are also inadequate to the task of displaying on demand the state of specific components. We describe an approach to improving the testability of complex software systems with software constructs modeled after the hardware JTAG bus, used to provide visibility and controllability in testing digital circuits.

Tamir, Yuval↗

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 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↗