Search NASA⌕ Search

SEARCH · Search NASA

Results for “software architecture”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Software Architecture to Support the Evolution of the ISRU RESOLVE Engineering Breadboard Unit 2 (EBU2)

The In-Situ Resource Utilization (ISRU) Regolith & Environmental Science and Oxygen & Lunar Volatiles Extraction (RESOLVE) software provides operation of the physical plant from a remote location with a high-level interface that can access and control the data from external software applications of other subsystems. This software allows autonomous control over the entire system with manual computer control of individual system/process components. It gives non-programmer operators the capability to easily modify the high-level autonomous sequencing while the software is in operation, as well as the ability to modify the low-level, file-based sequences prior to the system operation. Local automated control in a distributed system is also enabled where component control is maintained during the loss of network connectivity with the remote workstation. This innovation also minimizes network traffic. The software architecture commands and controls the latest generation of RESOLVE processes used to obtain, process, and quantify lunar regolith. The system is grouped into six sub-processes: Drill, Crush, Reactor, Lunar Water Resource Demonstration (LWRD), Regolith Volatiles Characterization (RVC) (see example), and Regolith Oxygen Extraction (ROE). Some processes are independent, some are dependent on other processes, and some are independent but run concurrently with other processes. The first goal is to analyze the volatiles emanating from lunar regolith, such as water, carbon monoxide, carbon dioxide, ammonia, hydrogen, and others. This is done by heating the soil and analyzing and capturing the volatilized product. The second goal is to produce water by reducing the soil at high temperatures with hydrogen. This is done by raising the reactor temperature in the range of 800 to 900 C, causing the reaction to progress by adding hydrogen, and then capturing the water product in a desiccant bed. The software needs to run the entire unit and all sub-processes; however, throughout testing, many variables and parameters need to be changed as more is learned about the system operation. The Master Events Controller (MEC) is run on a standard laptop PC using Windows XP. This PC runs in parallel to another laptop that monitors the GC, and a third PC that monitors the drilling/ crushing operation. These three PCs interface to the process through a CompactRIO, OPC Servers, and modems.

Moss, Thomas↗
NASA NTRS2006

Software Architecture of Sensor Data Distribution In Planetary Exploration

Data from mobile and stationary sensors will be vital in planetary surface exploration. The distribution and collection of sensor data in an ad-hoc wireless network presents a challenge. Irregular terrain, mobile nodes, new associations with access points and repeaters with stronger signals as the network reconfigures to adapt to new conditions, signal fade and hardware failures can cause: a) Data errors; b) Out of sequence packets; c) Duplicate packets; and d) Drop out periods (when node is not connected). To mitigate the effects of these impairments, a robust and reliable software architecture must be implemented. This architecture must also be tolerant of communications outages. This paper describes such a robust and reliable software infrastructure that meets the challenges of a distributed ad hoc network in a difficult environment and presents the results of actual field experiments testing the principles and actual code developed.

Lee, Charles↗
NASA NTRS2005

A Reusable and Adaptable Software Architecture for Embedded Space Flight System: The Core Flight Software System (CFS)

The contents include the following: High availability. Hardware is in harsh environment. Flight processor (constraints) very widely due to power and weight constraints. Software must be remotely modifiable and still operate while changes are being made. Many custom one of kind interfaces for one of a kind missions. Sustaining engineering. Price of failure is high, tens to hundreds of millions of dollars.

Wilmot, Jonathan↗
DOE OSTI2026

Autonomous elemental characterization enabled by a low cost robotic platform built upon a generalized software architecture

Despite the rapidly growing applications of robots in industry, the use of robots to automate tasks in scientific laboratories is less prolific due to the lack of generalized methodologies and the high cost of hardware. This paper focuses on the automation of characterization tasks necessary for reducing cost while maintaining generalization and proposes a software architecture for building robotic systems in scientific laboratory environments. A dual-layer (Socket.IO and ROS) action server design is the basic building block, which facilitates the implementation of a web-based front end for user-friendly operation and the use of ROS Behavior Trees for convenient task planning and execution. A robotic platform for automating mineral and material sample characterization is built upon the architecture, with an open-source, low-cost three-axis computer numerical control gantry system serving as the main robot. A handheld laser induced breakdown spectroscopy (LIBS) analyzer is integrated with a 3D printed adapter, enabling (1) automated 2D chemical mapping and (2) autonomous sample measurement (with the support of an RGB-Depth camera). We demonstrate the utility of automated chemical mapping by scanning the surface of a spodumene-bearing pegmatite core sample with a 1071-point dense hyperspectral map acquired at a rate of 1520 bits per second. Furthermore, we showcase the autonomy of the platform in terms of perception, dynamic decision-making, and execution, through a case study of LIBS measurement of multiple mineral samples. The platform enables controlled and autonomous chemical quantification in the laboratory that complements field-based measurements acquired with the same handheld device, linking resource exploration and processing steps in the supply chain for lithium-based battery materials.

Cao, Xuan [Lawrence Berkeley National Laboratory (↗
NASA NTRS2006

Next Generation System and Software Architectures: Challenges from Future NASA Exploration Missions

The four key objective properties of a system that are required of it in order for it to qualify as "autonomic" are now well-accepted-self-configuring, self-healing, self-protecting, and self-optimizing- together with the attribute properties-viz. self-aware, environment-aware, self-monitoring and self- adjusting. This paper describes the need for next generation system software architectures, where components are agents, rather than objects masquerading as agents, and where support is provided for self-* properties (both existing self-chop and emerging self-* properties). These are discussed as exhibited in NASA missions, and in particular with reference to a NASA concept mission, ANTS, which is illustrative of future NASA exploration missions based on the technology of intelligent swarms.

Sterritt, Roy↗
NASA NTRS1998

WARP3D-Release 10.8: Dynamic Nonlinear Analysis of Solids using a Preconditioned Conjugate Gradient Software Architecture

This report describes theoretical background material and commands necessary to use the WARP3D finite element code. WARP3D is under continuing development as a research code for the solution of very large-scale, 3-D solid models subjected to static and dynamic loads. Specific features in the code oriented toward the investigation of ductile fracture in metals include a robust finite strain formulation, a general J-integral computation facility (with inertia, face loading), an element extinction facility to model crack growth, nonlinear material models including viscoplastic effects, and the Gurson-Tver-gaard dilatant plasticity model for void growth. The nonlinear, dynamic equilibrium equations are solved using an incremental-iterative, implicit formulation with full Newton iterations to eliminate residual nodal forces. The history integration of the nonlinear equations of motion is accomplished with Newmarks Beta method. A central feature of WARP3D involves the use of a linear-preconditioned conjugate gradient (LPCG) solver implemented in an element-by-element format to replace a conventional direct linear equation solver. This software architecture dramatically reduces both the memory requirements and CPU time for very large, nonlinear solid models since formation of the assembled (dynamic) stiffness matrix is avoided. Analyses thus exhibit the numerical stability for large time (load) steps provided by the implicit formulation coupled with the low memory requirements characteristic of an explicit code. In addition to the much lower memory requirements of the LPCG solver, the CPU time required for solution of the linear equations during each Newton iteration is generally one-half or less of the CPU time required for a traditional direct solver. All other computational aspects of the code (element stiffnesses, element strains, stress updating, element internal forces) are implemented in the element-by- element, blocked architecture. This greatly improves vectorization of the code on uni-processor hardware and enables straightforward parallel-vector processing of element blocks on multi-processor hardware.

Koppenhoefer, Kyle C.↗
DOE OSTI2025

Node-red Software Architecture For Soec System Control

The software workflows that have been developed are open-source and therefore can be accessed and utilized by researchers and students all around the world for free of cost. The software is flexible and easily modifiable to suit the needs for testing bench-scale to system-level setups, and is not limited to just hydrogen generation facilities. The web-interface of the code allows for easy remote access and management, which is especially useful for distributed systems. This is more challenging with traditional PLCs, which often require direct connections or specialized software, making remote troubleshooting more cumbersome. Additionally, since the underlying interface is open-source, with an active community contributing to its development, regular updates, new features, and a wealth of community support and shared solutions will keep improving the overall architecture without excessive fees for upgrades.

Shigrekar, Amey [Idaho National Laboratory (INL), ↗
NASA NTRS2006

Implications of Responsive Space on the Flight Software Architecture

The Responsive Space initiative has several implications for flight software that need to be addressed not only within the run-time element, but the development infrastructure and software life-cycle process elements as well. The runtime element must at a minimum support Plug & Play, while the development and process elements need to incorporate methods to quickly generate the needed documentation, code, tests, and all of the artifacts required of flight quality software. Very rapid response times go even further, and imply little or no new software development, requiring instead, using only predeveloped and certified software modules that can be integrated and tested through automated methods. These elements have typically been addressed individually with significant benefits, but it is when they are combined that they can have the greatest impact to Responsive Space. The Flight Software Branch at NASA's Goddard Space Flight Center has been developing the runtime, infrastructure and process elements needed for rapid integration with the Core Flight software System (CFS) architecture. The CFS architecture consists of three main components; the core Flight Executive (cFE), the component catalog, and the Integrated Development Environment (DE). This paper will discuss the design of the components, how they facilitate rapid integration, and lessons learned as the architecture is utilized for an upcoming spacecraft.

Wilmot, Jonathan↗
NASA NTRS2004

Selection of a Data Acquisition and Controls System Communications and Software Architecture for Johnson Space Center's Space Environment Simulation Laboratory Thermal and Vacuum Test Facilities

Upgrade of data acquisition and controls systems software at Johnson Space Center's Space Environment Simulation Laboratory (SESL) involved the definition, evaluation and selection of a system communication architecture and software components. A brief discussion of the background of the SESL and its data acquisition and controls systems provides a context for discussion of the requirements for each selection. Further framework is provided as upgrades to these systems accomplished in the 1990s and in 2003 are compared to demonstrate the role that technological advances have had in their improvement. Both of the selections were similar in their three phases; 1) definition of requirements, 2) identification of candidate products and their evaluation and testing and 3) selection by comparison of requirement fulfillment. The candidates for the communication architecture selection embraced several different methodologies which are explained and contrasted. Requirements for this selection are presented and the selection process is described. Several candidates for the software component of the data acquisition and controls system are identified, requirements for evaluation and selection are presented, and the evaluation process is described.

Jordan, Eric A.↗
NASA NTRS2004

Software architecture for large scale, distributed, data-intensive systems

This paper presents our experience with OODT, a novel software architectual style, and middlware-based implementation for data-intensive systems. To date, OODT has been successfully evaluated in several different science domains including Cancer Research with the National Cancer Institute (NCI), and Planetary Science with NASA's Planetary Data System (PDS).

software architecture↗
NASA NTRS2008

Space Telecommunications Radio System Software Architecture Concepts and Analysis

The Space Telecommunications Radio System (STRS) project investigated various Software Defined Radio (SDR) architectures for Space. An STRS architecture has been selected that separates the STRS operating environment from its various waveforms and also abstracts any specialized hardware to limit its effect on the operating environment. The design supports software evolution where new functionality is incorporated into the radio. Radio hardware functionality has been moving from hardware based ASICs into firmware and software based processors such as FPGAs, DSPs and General Purpose Processors (GPPs). Use cases capture the requirements of a system by describing how the system should interact with the users or other systems (the actors) to achieve a specific goal. The Unified Modeling Language (UML) is used to illustrate the Use Cases in a variety of ways. The Top Level Use Case diagram shows groupings of the use cases and how the actors are involved. The state diagrams depict the various states that a system or object may be in and the transitions between those states. The sequence diagrams show the main flow of activity as described in the use cases.

Handler, Louis M.↗
DOE OSTI2026

Reference Hardware and Software Architecture for a Solenoid Pulser for Scientific Instrumentation at the National Ignition Facility

High current, high voltage solenoid pulser power systems for the generation of magnetic fields in a solenoid is not a radical or new concept. Despite being a cornerstone of scientific and weapons research for over 100 years, a commercial off the shelf unit easily configurable for a broad set of applications has yet to appear on the open market. Pulser systems are instead designed for specific target requirements. For gigawatt to terawatt systems, this is unavoidable. For megawatt systems however, many hundreds of thousands of dollars are wasted designing pulser systems from the ground up for clients, when it is possible to simply architect a modular system once that can have its capacitors swapped for many possible target applications. The National Ignition Facility (NIF) at the Lawrence Livermore National Laboratory (LLNL) is one such institution that would benefit from such a system, having bought such pulsers for several imaging systems. Ideally, all such a system would require is only a bachelors-level circuit analysis to find the correct capacitor values, as well as a written procedure to calibrate the software to correctly deliver the voltages required by the application. In this work, systems architecture and software engineering techniques are used to design and analyze such a system. Such a design, it is the hope of this author, will be used in scientific and engineering purposes in the future to build solenoid pulsers at the National Ignition Facility and other institutions to drastically cut development costs of scientific instrumentation.

42 ENGINEERING↗