Search NASA⌕ Search

SEARCH · Search NASA

Results for “system architectures”

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 289 records · Page 16
All sourcesNASA NTRSDOE OSTI
NASA NTRS1990

An architecture for rule based system explanation

A system architecture is presented which incorporate both graphics and text into explanations provided by rule based expert systems. This architecture facilitates explanation of the knowledge base content, the control strategies employed by the system, and the conclusions made by the system. The suggested approach combines hypermedia and inference engine capabilities. Advantages include: closer integration of user interface, explanation system, and knowledge base; the ability to embed links to deeper knowledge underlying the compiled knowledge used in the knowledge base; and allowing for more direct control of explanation depth and duration by the user. User models are suggested to control the type, amount, and order of information presented.

Fennel, T. R.↗
NASA NTRSDate not supplied

NASA's Identified Risk of Adverse Outcomes due to Inadequate Human Systems Integration Architecture

The NASA Human System Risk Board (HSRB) is responsible for tracking the evolution of the top ~30 human system risks identified to be associated with human spaceflight. As part of this process, the Board is charged with maintaining a consistent, integrated process to evaluate those risks and developing evidence-based risk posture recommendations. Risks are ranked by likelihood and consequence. Intermediate causal relationships between risk contributing factors and countermeasures that link hazards to outcomes are described using Directed Acyclic Graphs (DAGs). The DAGs are also useful for identifying common factors and countermeasures across the top 30 risks as well as communicating how astronaut exposure to spaceflight hazards leads to meaningful mission-level health and performance outcomes. One of the top risks tracked by the HSRB is The Risk of Adverse Outcomes Due to Inadequate Human-Systems Integration Architecture (HSIA). This risk captures the possibility that due to decreasing real-time ground support during missions beyond LEO, crew will be unable to adequately respond to unanticipated critical malfunctions or detect safety-critical procedural errors. The HSIA risk is ranked red (high) for Lunar surface and Mars missions due to the probability of Loss of Crew and Loss of Mission consequences. This paper describes the evidence that supports the HSIA risk ranking and presents the central narrative of the HSIA risk DAG-- i.e., anomaly detection, diagnosis, intervention, and task performance. Characterizations of the current state of practice for each of the DAG’s central nodes and the future tools needed for successful anomaly response are provided.

human-systems integration architecture↗
NASA NTRS1991

Advanced information processing system for advanced launch system: Avionics architecture synthesis

The Advanced Information Processing System (AIPS) is a fault-tolerant distributed computer system architecture that was developed to meet the real time computational needs of advanced aerospace vehicles. One such vehicle is the Advanced Launch System (ALS) being developed jointly by NASA and the Department of Defense to launch heavy payloads into low earth orbit at one tenth the cost (per pound of payload) of the current launch vehicles. An avionics architecture that utilizes the AIPS hardware and software building blocks was synthesized for ALS. The AIPS for ALS architecture synthesis process starting with the ALS mission requirements and ending with an analysis of the candidate ALS avionics architecture is described.

Lala, Jaynarayan H.↗
NASA NTRS2018

Exploration Medical System Technical Architecture Overview

The Exploration Medical Capability (ExMC) Element Systems Engineering (SE) goals include defining the technical system needed to support medical capabilities for a Mars exploration mission. A draft medical system architecture was developed based on stakeholder needs, system goals, and system behaviors, as captured in an ExMC concept of operations document and a system model. This talk will discuss a high-level view of the medical system, as part of a larger crew health and performance system, both of which will support crew during Deep Space Transport missions. Other mission components, such as the flight system, ground system, caregiver, and patient, will be discussed as aspects of the context because the medical system will have important interactions with each. Additionally, important interactions with other aspects of the crew health and performance system are anticipated, such as health & wellness, mission task performance support, and environmental protection. This talk will highlight areas in which we are working with other disciplines to understand these interactions.

Cerro, J.↗
NASA NTRS2006

Automated Synthesis of Architecture of Avionic Systems

The Architecture Synthesis Tool (AST) is software that automatically synthesizes software and hardware architectures of avionic systems. The AST is expected to be most helpful during initial formulation of an avionic-system design, when system requirements change frequently and manual modification of architecture is time-consuming and susceptible to error. The AST comprises two parts: (1) an architecture generator, which utilizes a genetic algorithm to create a multitude of architectures; and (2) a functionality evaluator, which analyzes the architectures for viability, rejecting most of the non-viable ones. The functionality evaluator generates and uses a viability tree a hierarchy representing functions and components that perform the functions such that the system as a whole performs system-level functions representing the requirements for the system as specified by a user. Architectures that survive the functionality evaluator are further evaluated by the selection process of the genetic algorithm. Architectures found to be most promising to satisfy the user s requirements and to perform optimally are selected as parents to the next generation of architectures. The foregoing process is iterated as many times as the user desires. The final output is one or a few viable architectures that satisfy the user s requirements.

Chau, Savio↗
NASA NTRS1992

Generic architectures for future flight systems

Generic architecture for future flight systems must be based on open system architectures (OSA). This provides the developer and integrator the flexibility to optimize the hardware and software systems to match diverse and unique applications requirements. When developed properly OSA provides interoperability, commonality, graceful upgradability, survivability and hardware/software transportability to greatly minimize life cycle costs and supportability. Architecture flexibility can be achieved to take advantage of commercial developments by basing these developments on vendor-neutral commercially accepted standards and protocols. Rome Laboratory presently has a program that addresses requirements for OSA.

Wood, Richard J.↗
NASA NTRS2010

Marshall Application Realignment System (MARS) Architecture

The Marshall Application Realignment System (MARS) Architecture project was established to meet the certification requirements of the Department of Defense Architecture Framework (DoDAF) V2.0 Federal Enterprise Architecture Certification (FEAC) Institute program and to provide added value to the Marshall Space Flight Center (MSFC) Application Portfolio Management process. The MARS Architecture aims to: (1) address the NASA MSFC Chief Information Officer (CIO) strategic initiative to improve Application Portfolio Management (APM) by optimizing investments and improving portfolio performance, and (2) develop a decision-aiding capability by which applications registered within the MSFC application portfolio can be analyzed and considered for retirement or decommission. The MARS Architecture describes a to-be target capability that supports application portfolio analysis against scoring measures (based on value) and overall portfolio performance objectives (based on enterprise needs and policies). This scoring and decision-aiding capability supports the process by which MSFC application investments are realigned or retired from the application portfolio. The MARS Architecture is a multi-phase effort to: (1) conduct strategic architecture planning and knowledge development based on the DoDAF V2.0 six-step methodology, (2) describe one architecture through multiple viewpoints, (3) conduct portfolio analyses based on a defined operational concept, and (4) enable a new capability to support the MSFC enterprise IT management mission, vision, and goals. This report documents Phase 1 (Strategy and Design), which includes discovery, planning, and development of initial architecture viewpoints. Phase 2 will move forward the process of building the architecture, widening the scope to include application realignment (in addition to application retirement), and validating the underlying architecture logic before moving into Phase 3. The MARS Architecture key stakeholders are most interested in Phase 3 because this is where the data analysis, scoring, and recommendation capability is realized. Stakeholders want to see the benefits derived from reducing the steady-state application base and identify opportunities for portfolio performance improvement and application realignment.

Belshe, Andrea↗
NASA NTRS1992

Architecture for Survivable Systems Processing (ASSP). Technology benefits for Open System Interconnects

The Architecture for Survivable Systems Processing (ASSP) program is a two phase program whose objective is the derivation, specification, development and validation of an open system architecture capable of supporting advanced processing needs of space, ground, and launch vehicle operations. The output of the first phase is a set of hardware and software standards and specifications defining this architecture at three levels. The second phase will validate these standards and develop the technology necessary to achieve strategic hardness, packaging density, throughput requirements, and interoperability/interchangeability.

Wood, Richard J.↗
NASA NTRS2004

Numerical Propulsion System Simulation Architecture

The Numerical Propulsion System Simulation (NPSS) is a framework for performing analysis of complex systems. Because the NPSS was developed using the object-oriented paradigm, the resulting architecture is an extensible and flexible framework that is currently being used by a diverse set of participants in government, academia, and the aerospace industry. NPSS is being used by over 15 different institutions to support rockets, hypersonics, power and propulsion, fuel cells, ground based power, and aerospace. Full system-level simulations as well as subsystems may be modeled using NPSS. The NPSS architecture enables the coupling of analyses at various levels of detail, which is called numerical zooming. The middleware used to enable zooming and distributed simulations is the Common Object Request Broker Architecture (CORBA). The NPSS Developer's Kit offers tools for the developer to generate CORBA-based components and wrap codes. The Developer's Kit enables distributed multi-fidelity and multi-discipline simulations, preserves proprietary and legacy codes, and facilitates addition of customized codes. The platforms supported are PC, Linux, HP, Sun, and SGI.

Naiman, Cynthia G.↗
NASA NTRSDate not supplied

Evaluating Lunar Water Processing System Model Configurations for Small Scale Oxygen and Hydrogen Production Within JAXA'S ISRU Technology

Introduction: In-Situ Resource Utilization (ISRU) refers to novel methods of extracting and processing local resources for use in life support and propulsion systems, reducing or eliminating the required consumables to be transferred from Earth. Current estimates of water-ice availability embedded in regolith within the Moon’s permanently shadowed regions (PSR’s) range between 1-5% by weight. However, the composition and characteristics of the “wet” regolith is unknown. Alternate ISRU excavation techniques and Concept of Operations (ConOps) must be explored to optimize surface system operations based on these factors. To assess the feasibility of different ISRU subsystem technologies and compare system architecture configurations, an interchangeable system model was generated to incorporate technologies spanning excavation of raw materials to storage of products and determine optimal arrangement of total system processing needs. Total Mass, Volume, and Power (M/V/P) requirements were computed for 168 design iterations of this water processing plant. System Model: In FY24, the System Engineering and Integration (SE&I) ISRU Modeling and Analysis (SIMA) team developed a lunar water processing system model using the Mission Analysis and Integration Tool (MAIT) to estimate the M/V/P for ISRU subsystems operating under a wide range of Hydrogen (H2) and Oxygen (O2) production targets for the Space Technology Mission Directorate (STMD) [1]. Based on Japan Aerospace Exploration Agency’s (JAXA) surface operational requirements, this system architecture was modified to include the ability to excavate consolidated icy regolith (versus granular ice excavation using Kennedy Space Center’s (KSC) ISRU Pilot Excavator, IPEx) and explore the feasibility of processing the lunar water both inside and outside of the PSR. For the consolidated icy regolith case study, excavation was performed via a mobility transport chassis outfitted with The Regolith Ice Drill for Exploring New Terrain (TRIDENT) for drilling [2] and the Cold Operable Lunar Deployable Arm (COLDArm) [3] for regolith transfer. The system model determines the required rover and payload. M/V/P to handle the required regolith processing rates. The regolith is then sorted and heated to sublimate the ice (via an auger dryer). The exiting high temperature, low pressure vapor is cleaned of volatiles (via cold trap) and electrolyzed to produce H2 and O2. These products are then dried, liquified with 20 K and 90 K cryocoolers (for H2 and O2, respectively), and stored in cylindrical tanks. Study Goals: Due to the different ConOps options of regolith transport to the ridge for processing versus processing it directly inside the PSR, as well as the unknown regolith/water-ice composition, new excavation techniques and their power configurations are being evaluated within a ISRU system architecture for production targets less than NASA’s pilot plant (1 mT). This analysis investigates the feasibility of numerous excavation techniques, power architectures, and logistical operations and determines an optimal system configuration with regards to M/V/P. It aims to investigate which parameters, both locally and globally, have the greatest effect on each subsystem within the plant. This can be used to identify the most critical components of the plant, and guide future decisions on allocating funding for research and development. The results from this study may provide subsystem developers with appropriate interfaces with excavation subsystems and downstream processes, and assessing the overall feasibility of each excavation technique, power architecture, and logistical timeframe. References: [1] Carlson, A. et. al. (2024) ICES. [2] Zacny, K., et. al. (2024) “ASCE Earth and Space”. [3] McCormick, R., et. Al. (2024) IEEE Xplore.

ISRU↗
DOE OSTI2025

Spent nuclear fuel receipt rate analysis within an integrated waste management system (IWMS) architecture that includes consolidated storage

A key parameter in analyzing the performance of an integrated waste management system (IWMS) architecture for the disposition of spent nuclear fuel (SNF) is the SNF receipt rate from reactor and other custodian sites. Receipt rate in this paper means how much SNF is accepted per year for transport in the IWMS from such sites. Introducing one or more federal consolidated interim storage facilities (CISFs) into the IWMS architecture can potentially accelerate the receipt rate profile over time relative to system architectures without a CISF. This raises the question of what an optimal SNF receipt rate profile for an IWMS architecture might be in view of practical constraints and desired system performance attributes and associated metrics. This paper describes a sensitivity study on SNF receipt rates and the associated results for a selected set of IWMS scenarios aimed at informing near-term planning for interim storage capabilities and transportation assets. Two different strategies for CISF operation while awaiting availability of a disposal system to receive SNF are compared: one that relatively quickly fills an initial CISF and then idles the transportation system; and another that aims for more continuous use of transportation assets and receipt capabilities at the CISF. This study examines cost considerations and other factors, such as the timing of clearing reactor sites of SNF, efficient use of capital assets, and some other metrics that might be important to a CISF host community. Based on the analysis, an initial approach is presented that targets a continuous receipt strategy while maintaining the flexibility to step up receipt capabilities to a reasonable degree when needed and beneficial, within overall system constraints.

11 - NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
NASA NTRSDate not supplied

NASA’s Identified Risks of Adverse Outcomes Due to Inadequate Human Systems Integration Architecture in Human Spaceflight

The NASA Human System Risk Board (HSRB) has the overall responsibility for tracking the evolution of the top ~30 human system risks that it has identified to be associated with human spaceflight. As part of this process, the Board is charged with maintaining a consistent, integrated process to mitigate those risks, and developing evidence-based risk posture recommendations. One of the identified risks is due to inadequate human systems integration architecture (HSIA) and a driving factor of this risk is that given decreasing real-time ground support for execution of complex operations during future exploration missions, there is a possibility of adverse performance outcomes including that crew are unable to adequately respond to unanticipated critical malfunctions or detect safety critical procedural errors. The HSRB uses Directed Acyclic Graphs (DAGs) as a communication tool for describing how astronaut exposure to spaceflight hazards leads to meaningful mission-level health and performance outcomes and as the basis for understanding intermediate causal relationships between risk contributing factors and countermeasures that link hazards to outcomes. The HSIA risk DAG will be presented and described. Historically, critical malfunctions requiring Crew/MCC management occurred at a rate of 1.7 times per year for ISS averaged over the lifetime and 3-4 times per year in the burn in phase for the vehicle. These averages do not include EVA data, which greatly increases the incident rate. Prior experience from the Apollo program showed 10/11 crewed missions experienced significant anomalies where crew relied heavily on MCC expertise in real-time. These failure patterns are in line with those observed in other complex engineered systems (e.g., oil rigs, launch systems, commercial aviation, etc.) It is likely that general malfunction and error rates are > 10% for short duration missions (<30 days), based on past and current spaceflight operations data. Likelihood of adverse outcomes has the potential to increase as crew conduct work with new, complex systems and with less ground support. For Low Earth Orbit missions and Lunar missions less than 30 days, assuming minimal comm delays, disruptions and bandwidth limitations, malfunctions and errors can affect mission objectives and crew health but may be mitigated by ground support. For Lunar missions greater than 30 days and any potential Mars mission malfunctions and errors can have Loss of Crew and Loss of Mission consequences due to reduced ground support (communication delays, constraints and blackouts) for more complex operations, as well as reduced resupply and evacuation options.

Daniel M Buckland↗
NASA NTRS2016

Computational Modeling to Limit the Impact Displays and Indicator Lights Have on Habitable Volume Operational Lighting Constraints

The goal of this investigation is to determine design limitations and architectural solutions that limit the impact light from displays and indicator lamps have on the operational environment task lighting and lighting countermeasure spectrum constraints. It is concerning that this innovative architectural lighting system, could be compromised by spectrums from display systems, architectural materials, and structures that are not considered as part a full system design implementation. The introduction of many Commercial Off the Shelf (COTS) products to the spacecraft volume that contain LEDs, without consideration to the human factors and biological constraints, is another problem. Displays and indicators are a necessary part of the spacecraft and it is the goal of this research project to determine constraints and solutions that allow these systems to be integrated while minimizing how the lighting environment is modified by them. Due to the potentially broad scope of this endeavor, the project team developed constraints for the evaluation. The evaluation will be on a set of tasks that required significant exposure in the same environment while having a large chance of impacting the light spectrum the crew is expected to receive from the architectural lighting system. The team plans to use recent HRP research on "Net Habitable Volume" [1] to provide the boundary conditions for volume size. A Zemax ® lighting model was developed of a small enclosure that had high intensity overhead lighting and a standard intensity display with LED indicator arrays. The computer model demonstrated a work surface illuminated at a high level by the overhead light source compared to displays and indicators whose light is parallel to the work plane. The overhead lighting oversaturated spectral contributions from the display and indicator at the task work surface. Interestingly, when the observer looked at the displays and LEDs within the small enclosure, their spectral contribution was significant but could be reduced by reflecting overhead light from the wall(s) to the observer. Direct observation of displays and LEDs are an issue because the user's viewing area is a display, not an illuminated work surface. Since avionics command centers consume significant crew time, the tasks that seemed at higher risk for unwanted spectral contributions as an operational volume with significant quantity of displays and indicators that were either under direct observation of the crew or impacting a volume the crew may be required to sleep in.

Clark, T. E.↗
NASA NTRSDate not supplied

Stochastic Verification by Analysis for Autonomous Systems Management Architecture (ASMA)

The Gateway Vehicle Systems Manager (VSM) is the top-level of a distributed, hierarchical software control system. VSM is data-driven and will make decisions related to mission, fault, resource management and vehicle control. These attributes combined with a high degree of autonomy make it susceptible to emergent behavior. In order to achieve the high level of confidence needed in this critical system, the VSM team has developed a multifaceted verification strategy employing traditional verification techniques, simulation, model checking, and runtime verification. Individual algorithms are verified using conventional testing and model checking using assume-guarantee contracts. A discrete event-based simulation approach is being developed to verify timelines. This presentation describes an enhancement to the verification approach using analysis to enhance system robustness by detecting and resolving the potential for emergent behavior. The verification by analysis employs a Software in the Loop (SITL) environment with real flight software executing on emulated processors, simulations of vehicle subsystems, flight dynamics, and human inputs. Since the possible input space and configuration data set are too large for exhaustive testing, a Monte Carlo approach is used to cover feasible scenarios, augmented with corner cases and known higher-risk scenarios. A key problem in using Monte Carlo-based system verification is evaluating test results to ensure that system behavior is correct. The presentation describes the approach the VSM team uses to monitor behavior for compliance with predetermined boundaries and to identify anomalous behavior for further analysis. This presentation describes the multi-level systems approach to verification, and the simulation-based layer that covers the feasible state space: 1. Overview of the Gateway VSM 2. Special challenges due to heterogeneous, hierarchical architecture 3. Modeling and simulation environment using flight software and system simulations 4. Developing input sets to ensure state-space coverage 5. Developing model and data configuration sets to ensure model coverage 6. Interpreting results without predetermined outcomes 7. Lessons learned and future work

Verification and Validation↗
NASA NTRS1990

Advanced embedded processing: Present and future

Integrated airframe/propulsion control system architecture is discussed. The main objectives of the program are: design and validation methodology for system architecture; system design; system specification; and small-scale system testing.

Cohen, Gerald C.↗
NASA NTRS2012

Space Telecommunications Radio System (STRS) Architecture: Tutorial - Overview - Part 1

Space Telecommunications Radio System (STRS) Architecture Standard provides a NASA standard for software-defined radio. STRS is being demonstrated in the Space Communications and Navigation (SCaN) Testbed formerly known as Communications, Navigation and Networking Configurable Testbed (CoNNeCT). Ground station radios communicating the SCaN testbed are also being written to comply with the STRS architecture. The STRS Architecture Tutorial Overview presents a general introduction to the STRS architecture standard developed at the NASA Glenn Research Center (GRC), addresses frequently asked questions, and clarifies methods of implementing the standard. The STRS architecture should be used as a base for many of NASA s future telecommunications technologies. The presentation will provide a basic understanding of STRS.

Handler, Louis M.↗