Search NASA⌕ Search

SEARCH · Search NASA

Results for “software engineering systems software architecture development”

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 181 records · Page 10

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗

Overview of the SLS Core Stage Thrust Vector Control System Design

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) consists of four independent hydraulic systems. The SLS CS TVC system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Each hydraulic system nominally provides hydraulic power to one RS-25 engine and two actuators. Additionally, each system provides redundant control capability to one actuator on each of its neighboring systems. The RS-25 uses hydraulic power to control propellant valves, and the TVC actuators are used to move the engine in the pitch and yaw gimbal planes. The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Solid Rocket Booster APU turbines are powered by hot gas produced by a catalyzed hydrazine decomposition. The SLS Core Auxiliary Power Unit (CAPU) is derived from the Space Shuttle Orbiter Auxiliary Power Unit (APU); on the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. The remaining hardware in the TVC system (hydraulic Filter Manifold (FM), hydraulic Supply Accumulator (SA), hydraulic Return Accumulator (RA), Hydraulic Reservoir, Exhaust Gas Heat Exchanger (EGHE)) as well as the avionics providing control and telemetry (TVC Actuator Controller (TAC) and CAPU Controller (CAPUC) are new components developed for SLS. This paper is the first installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the overall design architecture of the CS TVC is presented, with a focus on the interfaces between the TVC actuators, the engines, their hydraulic power systems, and the avionics that provide commands from the SLS Vehicle Management (VM) software to effect stable and robust flight control for the integrated SLS launch vehicle.

Thrust Vector Control↗

Executive control systems in the engineering design environment

Executive Control Systems (ECSs) are software structures for the unification of various engineering design application programs into comprehensive systems with a central user interface (uniform access) method and a data management facility. Attention is presently given to the most significant determinations of a research program conducted for 24 ECSs, used in government and industry engineering design environments to integrate CAD/CAE applications programs. Characterizations are given for the systems' major architectural components and the alternative design approaches considered in their development. Attention is given to ECS development prospects in the areas of interdisciplinary usage, standardization, knowledge utilization, and computer science technology transfer.

Hurst, P. W.↗

Onboard Nonlinear Engine Sensor and Component Fault Diagnosis and Isolation Scheme

A method detects and isolates in-flight sensor, actuator, and component faults for advanced propulsion systems. In sharp contrast to many conventional methods, which deal with either sensor fault or component fault, but not both, this method considers sensor fault, actuator fault, and component fault under one systemic and unified framework. The proposed solution consists of two main components: a bank of real-time, nonlinear adaptive fault diagnostic estimators for residual generation, and a residual evaluation module that includes adaptive thresholds and a Transferable Belief Model (TBM)-based residual evaluation scheme. By employing a nonlinear adaptive learning architecture, the developed approach is capable of directly dealing with nonlinear engine models and nonlinear faults without the need of linearization. Software modules have been developed and evaluated with the NASA C-MAPSS engine model. Several typical engine-fault modes, including a subset of sensor/actuator/components faults, were tested with a mild transient operation scenario. The simulation results demonstrated that the algorithm was able to successfully detect and isolate all simulated faults as long as the fault magnitudes were larger than the minimum detectable/isolable sizes, and no misdiagnosis occurred

Tang, Liang↗

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↗

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↗

SEXTANT X-Ray Pulsar Navigation Demonstration: Flight System and Test Results

The Station Explorer for X-ray Timing and Navigation Technology (SEXTANT) is a technology demonstration enhancement to the Neutron-star Interior Composition Explorer (NICER) mission. NICER is a NASA Explorer Mission of Opportunity that will be hosted on the International Space Station (ISS). SEXTANT will, for the first time, demonstrate real-time, on-board X-ray Pulsar Navigation (XNAV), a significant milestone in the quest to establish a GPS-like navigation capability available throughout our Solar System and beyond. This paper gives an overview of the SEXTANT system architecture and describes progress prior to environmental testing of the NICER flight instrument. It provides descriptions and development status of the SEXTANT flight software and ground system, as well as detailed description and results from the flight software functional and performance testing within the high-fidelity Goddard Space Flight Center (GSFC) X-ray Navigation Laboratory Testbed (GXLT) software and hardware simulation environment. Hardware-in-the-loop simulation results are presented, using the engineering model of the NICER timing electronics and the GXLT pulsar simulator-the GXLT precisely controls NASA GSFC's unique Modulated X-ray Source to produce X-rays that make the NICER detector electronics appear as if they were aboard the ISS viewing a sequence of millisecond pulsars

Pulsar↗

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

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

Geographic Information Systems and Web Page Development

The Facilities Engineering and Architectural Branch is responsible for the design and maintenance of buildings, laboratories, and civil structures. In order to improve efficiency and quality, the FEAB has dedicated itself to establishing a data infrastructure based on Geographic Information Systems, GIs. The value of GIS was explained in an article dating back to 1980 entitled "Need for a Multipurpose Cadastre which stated, "There is a critical need for a better land-information system in the United States to improve land-conveyance procedures, furnish a basis for equitable taxation, and provide much-needed information for resource management and environmental planning." Scientists and engineers both point to GIS as the solution. What is GIS? According to most text books, Geographic Information Systems is a class of software that stores, manages, and analyzes mapable features on, above, or below the surface of the earth. GIS software is basically database management software to the management of spatial data and information. Simply put, Geographic Information Systems manage, analyze, chart, graph, and map spatial information. At the outset, I was given goals and expectations from my branch and from my mentor with regards to the further implementation of GIs. Those goals are as follows: (1) Continue the development of GIS for the underground structures. (2) Extract and export annotated data from AutoCAD drawing files and construct a database (to serve as a prototype for future work). (3) Examine existing underground record drawings to determine existing and non-existing underground tanks. Once this data was collected and analyzed, I set out on the task of creating a user-friendly database that could be assessed by all members of the branch. It was important that the database be built using programs that most employees already possess, ruling out most AutoCAD-based viewers. Therefore, I set out to create an Access database that translated onto the web using Internet Explorer as the foundation. After some programming, it was possible to view AutoCAD files and other GIS-related applications on Internet Explorer, while providing the user with a variety of editing commands and setting options. I was also given the task of launching a divisional website using Macromedia Flash and other web- development programs.

Reynolds, Justin↗

Evolution of a Reconfigurable Processing Platform for a Next Generation Space Software Defined Radio

The National Aeronautics and Space Administration (NASA)Harris Ka-Band Software Defined Radio (SDR) is the first, fully reprogrammable space-qualified SDR operating in the Ka-Band frequency range. Providing exceptionally higher data communication rates than previously possible, this SDR offers in-orbit reconfiguration, multi-waveform operation, and fast deployment due to its highly modular hardware and software architecture. Currently in operation on the International Space Station (ISS), this new paradigm of reconfigurable technology is enabling experimenters to investigate navigation and networking in the space environment.The modular SDR and the NASA developed Space Telecommunications Radio System (STRS) architecture standard are the basis for Harris reusable, digital signal processing space platform trademarked as AppSTAR. As a result, two new space radio products are a synthetic aperture radar payload and an Automatic Detection Surveillance Broadcast (ADS-B) receiver. In addition, Harris is currently developing many new products similar to the Ka-Band software defined radio for other applications. For NASAs next generation flight Ka-Band radio development, leveraging these advancements could lead to a more robust and more capable software defined radio.The space environment has special considerations different from terrestrial applications that must be considered for any system operated in space. Each space mission has unique requirements that can make these systems unique. These unique requirements can make products that are expensive and limited in reuse. Space systems put a premium on size, weight and power. A key trade is the amount of reconfigurability in a space system. The more reconfigurable the hardware platform, the easier it is to adapt to the platform to the next mission, and this reduces the amount of non-recurring engineering costs. However, the more reconfigurable platforms often use more spacecraft resources. Software has similar considerations to hardware. Having an architecture standard promotes reuse of software and firmware. Space platforms have limited processor capability, which makes the trade on the amount of amount of flexibility paramount.

Telecommunication↗

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

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↗

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↗

Propulsion System Simulation Using the Toolbox for the Modeling and Analysis of Thermodynamic Systems (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.

aerothermodynamics↗

Autonomous Satellite Command and Control through the World Wide Web: Phase 3

NASA's New Millenium Program (NMP) has identified a variety of revolutionary technologies that will support orders of magnitude improvements in the capabilities of spacecraft missions. This program's Autonomy team has focused on science and engineering automation technologies. In doing so, it has established a clear development roadmap specifying the experiments and demonstrations required to mature these technologies. The primary developmental thrusts of this roadmap are in the areas of remote agents, PI/operator interface, planning/scheduling fault management, and smart execution architectures. Phases 1 and 2 of the ASSET Project (previously known as the WebSat project) have focused on establishing World Wide Web-based commanding and telemetry services as an advanced means of interfacing a spacecraft system with the PI and operators. Current automated capabilities include Web-based command submission, limited contact scheduling, command list generation and transfer to the ground station, spacecraft support for demonstrations experiments, data transfer from the ground station back to the ASSET system, data archiving, and Web-based telemetry distribution. Phase 2 was finished in December 1996. During January-December 1997 work was commenced on Phase 3 of the ASSET Project. Phase 3 is the subject of this report. This phase permitted SSDL and its project partners to expand the ASSET system in a variety of ways. These added capabilities included the advancement of ground station capabilities, the adaptation of spacecraft on-board software, and the expansion of capabilities of the ASSET management algorithms. Specific goals of Phase 3 were: (1) Extend Web-based goal-level commanding for both the payload PI and the spacecraft engineer; (2) Support prioritized handling of multiple PIs as well as associated payload experimenters; (3) Expand the number and types of experiments supported by the ASSET system and its associated spacecraft; (4) Implement more advanced resource management, modeling and fault management capabilities that integrate the space and ground segments of the space system hardware; (5) Implement a beacon monitoring test; (6) Implement an experimental blackboard controller for space system management; (7) Further define typical ground station developments required for Internet-based remote control and for full system automation of the PI-to-spacecraft link. Each of those goals is examined in the next section. Significant sections of this report were also published as a conference paper.

Cantwell, Brian↗

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

Economical graphics display system for flight simulation avionics

During the past academic year the focal point of this project has been to enhance the economical flight simulator system by incorporating it into the aero engineering educational environment. To accomplish this goal it was necessary to develop appropriate software modules that provide a foundation for student interaction with the system. In addition experiments had to be developed and tested to determine if they were appropriate for incorporation into the beginning flight simulation course, AERO-41B. For the most part these goals were accomplished. Experiments were developed and evaluated by graduate students. More work needs to be done in this area. The complexity and length of the experiments must be refined to match the programming experience of the target students. It was determined that few undergraduate students are ready to absorb the full extent and complexity of a real-time flight simulation. For this reason the experiments developed are designed to introduce basic computer architectures suitable for simulation, the programming environment and languages, the concept of math modules, evaluation of acquired data, and an introduction to the meaning of real-time. An overview is included of the system environment as it pertains to the students, an example of a flight simulation experiment performed by the students, and a summary of the executive programming modules created by the students to achieve a user-friendly multi-processor system suitable to an aero engineering educational program.

Source record↗