SEARCH · Search NASA

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

SourceResearch connectionFrom yearThrough year

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

At least 289 records · Page 16

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Apex Reference Manual 3.0 Beta

Apex is a toolkit for constructing software that behaves intelligently and responsively in demanding task environments. Reflecting its origin at NASA where Apex continues to be developed, current applications include: a) Providing autonomous mission management and tactical control capabilities for unmanned aerial vehicles including an autonomous surveillance helicopter and a simulation prototype of an unmanned fixed-wing aircraft to be used for wildfire mapping; b) Simulating human air traffic controllers, pilots and astronauts to help predict how people might respond to changes in equipment or procedures; and c) Predicting the precise duration and sequence of routine human behaviors based on a human-computer interaction engineering technique called CPM-GOMS. Among Apex s components are a set of implemented reasoning services, such as those for reactive planning and temporal pattern recognition; a software architecture that embeds and integrates these services and allows additional reasoning elements to be added as extensions; a formal language for specifying agent knowledge; a simulation environment to facilitate prototyping and analysis; and Sherpa, a set of tools for visualizing autonomy logic and runtime behavior. In combination, these are meant to provide a flexible and usable framework for creating, testing, and deploying intelligent agent software. Overall, our goal in developing Apex is to lower economic barriers to developing intelligent software agents. New ideas about how to extend or modify the system are evaluated in terms of their impact in reducing the time, expertise, and inventiveness required to build and maintain applications. For example, potential enhancements to the AI reasoning capabilities in the system are reviewed not only for usefulness and distinctiveness, but also for their impact on the readability and general usability of Apex s behavior representation language (PDL) and on the transparency of resulting behavior. A second central part of our approach is to iteratively refine Apex based on lessons learned from as diverse a set of applications as possible. Many applications have been developed by users outside the core development team including engineers, researchers, and students. Usability is thus a central concern for every aspect of Apex visible to a user, including PDL, Sherpa, the Apex installation process, APIs, and user documentation. Apex users vary in their areas of expertise and in their familiarity with autonomy technology. Focusing on usability, a development philosophy summarized by the project motto "Usable Autonomy," has been important part of enabling diverse users to employ Apex successfully and to provide feedback needed to guide iterative, user-centered refinement.

Freed, Michael A.↗

NASA NTRS1985

Executive control systems in the engineering design environment

An executive control system (ECS) is a software structure for unifying various applications codes into a comprehensive system. It provides a library of applications, a uniform access method through a cental user interface, and a data management facility. A survey of twenty-four executive control systems designed to unify various CAD/CAE applications for use in diverse engineering design environments within government and industry was conducted. The goals of this research were to establish system requirements to survey state-of-the-art architectural design approaches, and to provide an overview of the historical evolution of these systems. Foundations for design are presented and include environmental settings, system requirements, major architectural components, and a system classification scheme based on knowledge of the supported engineering domain(s). An overview of the design approaches used in developing the major architectural components of an ECS is presented with examples taken from the surveyed systems. Attention is drawn to four major areas of ECS development: interdisciplinary usage; standardization; knowledge utilization; and computer science technology transfer.

Hurst, P. W.↗

NASA NTRS2000

Using XML and Java for Astronomical Instrumentation Control

Traditionally, instrument command and control systems have been highly specialized, consisting mostly of custom code that is difficult to develop, maintain, and extend. Such solutions are initially very costly and are inflexible to subsequent engineering change requests, increasing software maintenance costs. Instrument description is too tightly coupled with details of implementation. NASA Goddard Space Flight Center is developing a general and highly extensible framework that applies to any kind of instrument that can be controlled by a computer. The software architecture combines the platform independent processing capabilities of Java with the power of the Extensible Markup Language (XML), a human readable and machine understandable way to describe structured data. A key aspect of the object-oriented architecture is software that is driven by an instrument description, written using the Instrument Markup Language (IML). ]ML is used to describe graphical user interfaces to control and monitor the instrument, command sets and command formats, data streams, and communication mechanisms. Although the current effort is targeted for the High-resolution Airborne Wideband Camera, a first-light instrument of the Stratospheric Observatory for Infrared Astronomy, the framework is designed to be generic and extensible so that it can be applied to any instrument.

Ames, Troy↗

NASA NTRS2003

Advantages of Brahms for Specifying and Implementing a Multiagent Human-Robotic Exploration System

We have developed a model-based, distributed architecture that integrates diverse components in a system designed for lunar and planetary surface operations: an astronaut's space suit, cameras, all-terrain vehicles, robotic assistant, crew in a local habitat, and mission support team. Software processes ('agents') implemented in the Brahms language, run on multiple, mobile platforms. These mobile agents interpret and transform available data to help people and robotic systems coordinate their actions to make operations more safe and efficient. The Brahms-based mobile agent architecture (MAA) uses a novel combination of agent types so the software agents may understand and facilitate communications between people and between system components. A state-of-the-art spoken dialogue interface is integrated with Brahms models, supporting a speech-driven field observation record and rover command system. An important aspect of the methodology involves first simulating the entire system in Brahms, then configuring the agents into a runtime system Thus, Brahms provides a language, engine, and system builder's toolkit for specifying and implementing multiagent systems.

Clancey, William J.↗

NASA NTRS2005

Situation Awareness of Onboard System Autonomy

We have developed intelligent agent software for onboard system autonomy. Our approach is to provide control agents that automate crew and vehicle systems, and operations assistants that aid humans in working with these autonomous systems. We use the 3 Tier control architecture to develop the control agent software that automates system reconfiguration and routine fault management. We use the Distributed Collaboration and Interaction (DCI) System to develop the operations assistants that provide human services, including situation summarization, event notification, activity management, and support for manual commanding of autonomous system. In this paper we describe how the operations assistants aid situation awareness of the autonomous control agents. We also describe our evaluation of the DCI System to support control engineers during a ground test at Johnson Space Center (JSC) of the Post Processing System (PPS) for regenerative water recovery.

Schreckenghost, Debra↗

DOE OSTI2025

An Approach to Automate tools for the Risk Assessment of Digital Instrumentation and Control Systems

Reliable digital instrumentation and control systems (DI&C) are integral for sustaining the continued operation of nuclear power plants. These systems ensure that nuclear reactors operate safely, efficiently, and within regulatory requirements. Yet, the cost of designing and licensing new nuclear DI&C can be prohibitively expensive. Under the U.S. Department of Energy Light Water Reactor Sustainability Program, Idaho National Laboratory has developed a framework for supporting the risk-informed design of DI&C systems by offering methods to support the identification, quantification, and evaluation of risks for various DI&C design architectures. The framework indicates potential software failure modes and provides pathways for quantifying the potential for these software failures, including common cause failures. Using the framework’s systematic approach, challenges for assessing risks within new and existing nuclear DI&C systems can be reduced. Nevertheless, the current framework can be further improved using the convenience of automation. This paper introduces the development of Software for the Hazard Identification and Evaluation of Digital Systems (SHIELDS). SHIELDS is an engineering software package that enables the identification, elimination, and mitigation of potential risks and reduces the burden of deploying reliable DI&C systems. This work introduces plans and techniques to digitize and improve the manual risk assessment modules of the framework. These improvements will save time and increase the repeatability and usability of the framework, making it more accessible to a wider range of users. Ultimately, this introduces SHIELDS and how its modules support efficient development of safe and reliable DI&C systems.

46 - INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AN↗

NASA NTRS2002

Software Engineering Support of the Third Round of Scientific Grand Challenge Investigations: Earth System Modeling Software Framework Survey

One of the most significant challenges in large-scale climate modeling, as well as in high-performance computing in other scientific fields, is that of effectively integrating many software models from multiple contributors. A software framework facilitates the integration task, both in the development and runtime stages of the simulation. Effective software frameworks reduce the programming burden for the investigators, freeing them to focus more on the science and less on the parallel communication implementation. while maintaining high performance across numerous supercomputer and workstation architectures. This document surveys numerous software frameworks for potential use in Earth science modeling. Several frameworks are evaluated in depth, including Parallel Object-Oriented Methods and Applications (POOMA), Cactus (from (he relativistic physics community), Overture, Goddard Earth Modeling System (GEMS), the National Center for Atmospheric Research Flux Coupler, and UCLA/UCB Distributed Data Broker (DDB). Frameworks evaluated in less detail include ROOT, Parallel Application Workspace (PAWS), and Advanced Large-Scale Integrated Computational Environment (ALICE). A host of other frameworks and related tools are referenced in this context. The frameworks are evaluated individually and also compared with each other.

Talbot, Bryan↗

NASA NTRS1991

Guidance, navigation, and control subsystem equipment selection algorithm using expert system methods

Enhanced engineering tools can be obtained through the integration of expert system methodologies and existing design software. The application of these methodologies to the spacecraft design and cost model (SDCM) software provides an improved technique for the selection of hardware for unmanned spacecraft subsystem design. The knowledge engineering system (KES) expert system development tool was used to implement a smarter equipment section algorithm than that which is currently achievable through the use of a standard data base system. The guidance, navigation, and control subsystems of the SDCM software was chosen as the initial subsystem for implementation. The portions of the SDCM code which compute the selection criteria and constraints remain intact, and the expert system equipment selection algorithm is embedded within this existing code. The architecture of this new methodology is described and its implementation is reported. The project background and a brief overview of the expert system is described, and once the details of the design are characterized, an example of its implementation is demonstrated.

Allen, Cheryl L.↗

NASA NTRS2003

Human Factors Engineering Requirements for the International Space Station - Successes and Challenges

Advanced technology coupled with the desire to explore space has resulted in increasingly longer human space missions. Indeed, any exploration mission outside of Earth's neighborhood, in other words, beyond the moon, will necessarily be several months or even years. The International Space Station (ISS) serves as an important advancement toward executing a successful human space mission that is longer than a standard trip around the world or to the moon. The ISS, which is a permanently occupied microgravity research facility orbiting the earth, will support missions four to six months in duration. In planning for the ISS, the NASA developed an agency-wide set of human factors standards for the first time in a space exploration program. The Man-Systems Integration Standard (MSIS), NASA-STD-3000, a multi-volume set of guidelines for human-centered design in microgravity, was developed with the cooperation of human factors experts from various NASA centers, industry, academia, and other government agencies. The ISS program formed a human factors team analogous to any major engineering subsystem. This team develops and maintains the human factors requirements regarding end-to-end architecture design and performance, hardware and software design requirements, and test and verification requirements. It is also responsible for providing program integration across all of the larger scale elements, smaller scale hardware, and international partners.

Whitmore, M.↗

NASA NTRS2014

Propulsion System Simulation Using the Toolbox for the Modeling and Analysis of Thermodynamic System T-MATS

A simulation toolbox has been developed for the creation of both steady-state and dynamic thermodynamic software models. This paper describes the Toolbox for the Modeling and Analysis of Thermodynamic Systems (T-MATS), which combines generic thermodynamic and controls modeling libraries with a numerical iterative solver to create a framework for the development of thermodynamic system simulations, such as gas turbine engines. The objective of this paper is to present an overview of T-MATS, the theory used in the creation of the module sets, and a possible propulsion simulation architecture. A model comparison was conducted by matching steady-state performance results from a T-MATS developed gas turbine simulation to a well-documented steady-state simulation. Transient modeling capabilities are then demonstrated when the steady-state T-MATS model is updated to run dynamically.

gas path dynamics↗

NASA NTRS2014

Propulsion System Simulation Using the Toolbox for the Modeling and Analysis of Thermodynamic System (T-MATS)

A simulation toolbox has been developed for the creation of both steady-state and dynamic thermodynamic software models. This presentation describes the Toolbox for the Modeling and Analysis of Thermodynamic Systems (T-MATS), which combines generic thermodynamic and controls modeling libraries with a numerical iterative solver to create a framework for the development of thermodynamic system simulations, such as gas turbine engines. The objective of this presentation is to present an overview of T-MATS, the theory used in the creation of the module sets, and a possible propulsion simulation architecture.

aerothermodynamics↗

NASA NTRS2014

Propulsion System Simulation Using the Toolbox for the Modeling and Analysis of Thermodynamic Systems (T-MATS)

aerothermodynamics↗

NASA NTRS1990

Advanced engineering software for in-space assembly and manned planetary spacecraft

Meeting the objectives of the Lunar/Mars initiative to establish safe and cost-effective extraterrestrial bases requires an integrated software/hardware approach to operational definitions and systems implementation. This paper begins this process by taking a 'software-first' approach to systems design, for implementing specific mission scenarios in the domains of in-space assembly and operations of the manned Mars spacecraft. The technological barriers facing implementation of robust operational systems within these two domains are discussed, and preliminary software requirements and architectures that resolve these barriers are provided.

Delaquil, Donald↗

NASA NTRSDate not supplied

Digital Prototyping Methods to Enable Product Development Analysis Cycle Compression in Aerospace Systems

Historically, the product development life cycle (spanning from origination of a systems concept to initial delivery or fielding) for large-scale aerospace systems is 10-25 years. Examples of recent programs exhibiting this timeline are the Space Shuttle (13 years), , International Space Station (18 years), NASA Hubble telescope (16 years), USAF F-35 Strike Fighter (22 years), Missile Defense Agency THAAD (21 years), USAF V-22 Osprey (26 years), USAF B-2 Spirt (19 years), US Army RAH-66 Comanche (22 years, cancelled prior to fielding), James Webb Space Telescope (25 years), Space Launch System (10 years). This list illustrates the challenges of developing and fielding a modern integrated multi-disciplinary aerospace system. These development timelines are often preceded by significant research and development programs and followed by multiple increments, blocks, or spirals to reach planned operational capability. In the modern era of aerospace system acquisition, there is significant pressure to reduce system development timelines to meet system objectives and enable competitiveness in the current industry and landscape. Across the aerospace industry, a range of rapid acquisition and prototyping programs are seeking to achieve system development within timelines considerably less than 10 years. Notably, in September of 2019, NASA issued a solicitation for the development and demonstration of a Human Landing System (HLS) to deliver humans to the lunar surface by 2024 (5 years) and for the development and demonstration of a more sustainable HLS by 2026 (7 years). Lengthy product development cycle timelines are a product of multiple factors ranging from programmatic, sociological, technical, and systems engineering issues. New approaches in systems engineering provide new ways to enable these compressed development timelines. These approaches employ expanded application of advanced systems engineering methods and cross-cutting digital tools to accelerate system development, utilizing digital prototyping to connect maturing sub-system or component technologies into system or system-of-systems hardware prototypes. Approaches such as the use of system integrating physics relationships to reduce the number of design analysis cycle iterations and state analysis modeling to reduce necessary software testing (and improving coverage of system execution scenarios) represent steps forward in reducing the engineering time needed to field new systems. In addition to cost, schedule and performance benefits, expanded digital exploration and demonstration reduce risk in live system test and demonstration. This incremental demonstration approach, where digital prototyping and demonstration leads and informs full system test and demonstration, could be more important for space applications because of the increased difficulty of test and demonstration of space systems and architectures. The Advanced Concepts Office (ACO) at Marshall Space Flight Center merges traditional multi-disciplinary concept definition methods with modern, cross-cutting systems engineering concepts to enable iterative design and analysis of space architectures and systems through coordinated, strategic management of human capital, technical processes, and technology. This paper provides an overview of that approach, including recent examples and a strategic path forward to enabling continued reduction of aerospace system product development life cycles.

Michael D Watson↗

NASA NTRS2006

Crew Launch Vehicle (CLV) Upper Stage Configuration Selection Process

The Crew Launch Vehicle (CLV), a key component of NASA's blueprint for the next generation of spacecraft to take humans back to the moon, is being designed and built by engineers at NASA s Marshall Space Flight Center (MSFC). The vehicle s design is based on the results of NASA's 2005 Exploration Systems Architecture Study (ESAS), which called for development of a crew-launch system to reduce the gap between Shuttle retirement and Crew Exploration Vehicle (CEV) Initial Operating Capability, identification of key technologies required to enable and significantly enhance these reference exploration systems, and a reprioritization of near- and far-term technology investments. The Upper Stage Element (USE) of the CLV is a clean-sheet approach that is being designed and developed in-house, with element management at MSFC. The USE concept is a self-supporting cylindrical structure, approximately 115' long and 216" in diameter, consisting of the following subsystems: Primary Structures (LOX Tank, LH2 Tank, Intertank, Thrust Structure, Spacecraft Payload Adaptor, Interstage, Forward and Aft Skirts), Secondary Structures (Systems Tunnel), Avionics and Software, Main Propulsion System, Reaction Control System, Thrust Vector Control, Auxiliary Power Unit, and Hydraulic Systems. The ESAS originally recommended a CEV to be launched atop a four-segment Space Shuttle Main Engine (SSME) CLV, utilizing an RS-25 engine-powered upper stage. However, Agency decisions to utilize fewer CLV development steps to lunar missions, reduce the overall risk for the lunar program, and provide a more balanced engine production rate requirement prompted engineers to switch to a five-segment design with a single Saturn-derived J-2X engine. This approach provides for single upper stage engine development for the CLV and an Earth Departure Stage, single Reusable Solid Rocket Booster (RSRB) development for the CLV and a Cargo Launch Vehicle, and single core SSME development. While the RSRB design has changed since the CLV Project's inception, the USE design has remained essentially a clean-sheet approach. Although a clean-sheet upper stage design inherently carries more risk than a modified design, it does offer many advantages: a design for increased reliability; built-in extensibility to allow for commonality/growth without major redesign; and incorporation of state-of-the-art materials, hardware, and design, fabrication, and test techniques and processes to facilitate a potentially better, more reliable system. Because consideration was given in the ESAS to both clean-sheet and modified USE designs, this paper will highlight the advantages and disadvantages of both approaches and provide a detailed discussion of trades/selections made that led to the final upper stage configuration.

Davis, Daniel J.↗

NASA NTRS1979

Numerical aerodynamic simulation facility feasibility study, executive summary

There were three major issues examined in the feasibility study. First, the ability of the proposed system architecture to support the anticipated workload was evaluated. Second, the throughput of the computational engine (the flow model processor) was studied using real application programs. Third, the availability, reliability, and maintainability of the system were modeled. The evaluations were based on the baseline systems. The results show that the implementation of the Numerical Aerodynamic Simulation Facility, in the form considered, would indeed be a feasible project with an acceptable level of risk. The technology required (both hardware and software) either already exists or, in the case of a few parts, is expected to be announced this year.

Source record↗

NASA NTRS1979

Numerical aerodynamic simulation facility feasibility study

There were three major issues examined in the feasibility study. First, the ability of the proposed system architecture to support the anticipated workload was evaluated. Second, the throughput of the computational engine (the flow model processor) was studied using real application programs. Third, the availability reliability, and maintainability of the system were modeled. The evaluations were based on the baseline systems. The results show that the implementation of the Numerical Aerodynamic Simulation Facility, in the form considered, would indeed be a feasible project with an acceptable level of risk. The technology required (both hardware and software) either already exists or, in the case of a few parts, is expected to be announced this year. Facets of the work described include the hardware configuration, software, user language, and fault tolerance.

Source record↗

NASA NTRS1992

CCD data acquisition systems at Lick and Keck Observatories

This paper will describe and compare two distinct but related CCD data acquisition systems (DAS) currently under development at Lick and Keck Observatories. Although these two systems have a number of major architectural differences, they share a considerable amount of common hardware and software. Both of these new systems build on a large body of proven software that is the foundation of the existing CCD DAS currently in use at Lick Observatory. Both will provide support for reading up to four on-chip amplifiers per CCD and/or reading out mosaics of CCD chips. In addition, they will provide the capability for interactive, real-time adjustment of CCD waveforms for engineering purposes. Each of these two systems is composed of three major subsystems: (1) an instrument computer and its software; (2) a data capture computer and its software; and (3) a CCD/dewar controller and its software. The instrument computer is a Unix workstation, and the functions it provides include user interfaces, the interactive real-time display of CCD images, and the recording of image and FITS header data to disk and/or tape. The data capture computer is responsible for the packaging and high-speed transfer of the CCD pixel data stream into a bulk RAM, and the subsequent transfer of this data to the instrument computer. The CCD/dewar controller generates the waveforms for clocking the CCD, digitizes the pixel data, and transmits it via high-speed link to the data capture computer. It is also responsible for monitoring and controlling the dewar temperature and cryogen levels. Given the number of different types of processors and high-speed data links employed in both systems, a major emphasis of this paper will be on the various forms of interprocessor communications utilized for data transfer and distributed process synchronization.

Kibrick, R. I.↗