SEARCH · Engineering Papers
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.
Program detects hardware failure in servosystems by comparing actual servo valve position with predictions of software model. In addition, system will also pick up most computer input/output failures. Process presents faster and more reliable results than previous failure detection methods.
New approach reduces repetitive development of features common to different applications. High-level programming language and interactive environment with access to graphical hardware and software created by adding graphical commands and other constructs to standardized, general-purpose programming language, "Scheme". Designed for use in developing other software incorporating interactive computer-graphics capabilities into application programs. Provides alternative to programming entire applications in C or FORTRAN, specifically ameliorating design and implementation of complex control and data structures typifying applications with interactive graphics. Enables experimental programming and rapid development of prototype software, and yields high-level programs serving as executable versions of software-design documentation.
Existing fault-tolerant clock synchronization algorithms are compared and contrasted. These include the following: software synchronization algorithms, such as convergence-averaging, convergence-nonaveraging, and consistency algorithms, as well as probabilistic synchronization; hardware synchronization algorithms; and hybrid synchronization. The worst-case clock skews guaranteed by representative algorithms are compared, along with other important aspects such as time, message, and cost overhead imposed by the algorithms. More recent developments such as hardware-assisted software synchronization and algorithms for synchronizing large, partially connected distributed systems are especially emphasized.
This document contains installation information for the Software Management Environment (SME), developed for the Systems Development Branch (Code 552) of the Flight Dynamics Division of Goddard Space Flight Center (GSFC). The SME provides an integrated set of management tools that can be used by software development managers in their day-to-day management and planning activities. This document provides a list of hardware and software requirements as well as detailed installation instructions and trouble-shooting information.
Environmental management, impact assessment, research and monitoring are multidisciplinary activities which are ideally suited to incorporate a multi-media approach to environmental problem solving. Geographic information systems (GIS), simulation models, neural networks and expert-system software are some of the advancing technologies being used for data management, query, analysis and display. At the 140,000 acre John F. Kennedy Space Center, the Advanced Software Technology group has been supporting development and implementation of a program that integrates these and other rapidly evolving hardware and software capabilities into a comprehensive Mapping, Analysis and Planning System (MAPS) based in a workstation/local are network environment. An expert-system shell is being developed to link the various databases to guide users through the numerous stages of a facility siting and environmental assessment. The expert-system shell approach is appealing for its ease of data access by management-level decision makers while maintaining the involvement of the data specialists. This, as well as increased efficiency and accuracy in data analysis and report preparation, can benefit any organization involved in natural resources management.
Over 39 years and a long list of missions, the guidance, navigation, and control (GN&C) groups at the Goddard Space Flight Center have gradually developed approaches to the design and implementation of successful spacecraft attitude control systems. With the recent creation of the Guidance, Navigation, and Control Center at Goddard, there is a desire to document some of these design practices to help to ensure their consistent application in the future. In this paper, we will discuss the beginnings of this effort, drawing primarily on the experience of one of the past attitude control system (ACS) groups at Goddard (what was formerly known as Code 712, the Guidance, Navigation, and Control Branch). We will discuss the analysis and design methods and criteria used, including guidelines for linear and nonlinear analysis, as well as the use of low- and high-fidelity simulation for system design and verification of performance. Descriptions of typical ACS sensor and actuator hardware will be shown, and typical sensor/actuator suites for a variety of mission types detailed. A description of the software and hardware test effort will be given, along with an attempt to make some qualitative estimates on how much effort is involved. The spacecraft and GN&C subsystem review cycles will be discussed, giving an outline of what design reviews are typically held and what information should be presented at each stage. Finally, we will point out some of the lessons learned at Goddard.
Over 39 years and a long list of missions, the guidance, navigation, and control (GN&C) groups at the Goddard Space Flight Center have gradually developed approaches to the design and implementation of successful spacecraft attitude control systems. With the recent creation of the Guidance, Navigation, and Control Center at Goddard, there is a desire to document some of these design practices to help to ensure their consistent application in the future. In this paper, we will discuss the beginnings of this effort, drawing primarily on the experience of one of the past attitude control system (ACS) groups at Goddard (what was formerly known as Code 712, the Guidance, Navigation, and Control Branch). We will discuss the analysis and design methods and criteria used, including guidelines for linear and nonlinear analysis, as well as the use of low- and high-fidelity simulation for system design and verification of performance. Descriptions of typical ACS sensor and actuator hardware will be shown, and typical sensor/actuator suites for a variety of mission types detailed. A description of the software and hardware test effort will be given, along with an attempt to make some qualitative estimates on how much effort is involved. The spacecraft and GN&C subsystem review cycles will be discussed, giving an outline of what design reviews are typically held and .what information should be presented at each stage. Finally, we will point out some of the lessons learned at Goddard.
The iPAS is an integrated hardware/software test and evaluation environment, in support of current and future spacecraft development The iPAS has two main elements. A common avionics, hardware, and software architecture that can be applied over various missions. A common testbed framework that supports integrated hardware/software testing for a variety of applications. The iPAS includes the following (non-flight qualified) components: Core Flight Software (from GSFC). Commercially available Proton and S950 Flight Computer boards. Power and propulsion systems based on representative flight hardware. A realistic flight deck based on the Multi-Purpose Crew Vehicle (MPCV), including realistic flight controls and displays. A Space Data System based on CCSDS protocols.
The Engineering and Technology Directorate (NE) at National Aeronautics and Space Administration (NASA) Kennedy Space Center (KSC) is designing a new command and control system for the checkout and launch of Space Launch System (SLS) and future rockets. The purposes of the semester long internship as a remote application software developer include the design, development, integration, and verification of the software and hardware in the firing rooms, in particular with the Mobile Launcher (ML) Launch Accessories (LACC) subsystem. In addition, a software test verification procedure document was created to verify and checkout LACC software for Launch Equipment Test Facility (LETF) testing.
The occurrence of faults in aerospace system hardware and software have consequences ranging from minor effects to catastrophic effects, and such faults can directly affect the safety of hardware and personnel. There are many origins to fault conditions, and the hardware that is capable of still meeting its performance requirements after experiencing itself a fault is said to be fault tolerant. A fault tolerant hardware is capable of detecting, isolating, and recovering from a fault condition; and this is a subfield of control engineering. An aerospace system that has been shown to have electromagnetic compatibility (EMC) in all its subsystems and systems cannot induced faults caused by electromagnetic interference (EMI). It can be proposed that the presence of EMI (or lack of EMC) is analogous to a potential fault initiator and the effects can likewise range from minor to severe. This paper starts by addressing the consequences of hardware failure in aerospace systems from a fault perspective, because the design of fault tolerant system is a major endeavor in aerospace. To arrive to this goal the paper starts with the concepts of fault, fault propagation, and a new concept called fault containment region. The paper then proceeds to provide two very recent examples in the aircraft industry of fault propagation with catastrophic effects. The paper proceeds to introduce the concept of EMI fault containment and a brief introduction to another new concept called the EMI containment region. The paper proceeds with an example of EMI fault containment region. The paper ends with a lesson learned conclusions.
A study was conducted to determine how major improvements in spacecraft computer systems can be obtained from recent advances in hardware and software technology. Investigations into integrated circuit technology indicated that the CMOS/SOS chip set being developed for the Air Force Avionics Laboratory at Wright Patterson had the best potential for improving the performance of spaceborne computer systems. An integral part of the chip set is the bit slice arithmetic and logic unit. The flexibility allowed by microprogramming, combined with the software investigations, led to the specification of a baseline architecture and instruction set.
The programmable pilot oriented display (P-POD), a multiprocessor based flight information processing and display unit, is discussed. Communication protocols between the three Z-80 processors inside P-POD are reviewed. The interface between the video processor, P2, and the main processor, P1, was tested. Hardware and software were revised. Data flow between P1 and P2 is illustrated. While running diagnostic routines to exercise the P1/P2 interface at maximum speed an intermittent failure was observed. A check of possible noise sources or race conditions in the hardware did not reveal the source of this failure. Possible software timing problems were also fully investigated. To eliminate the effects of this type of failure a performance monitor routine was used to detect these occasional failures and correct them. The data transmission cycle between P1/P2 is either allowed to continue normal operation or is re-initialized and restarted when an error is detected.
Progress in numerical weather and climate prediction accuracy greatly depends on the growth of the available computing power. As the number of cores in top computing facilities pushes into the millions, increased average frequency of hardware and software failures forces users to review their algorithms and systems in order to protect simulations from breakdown. This report surveys hardware, application-level and algorithm-level resilience approaches of particular relevance to time-critical numerical weather and climate prediction systems. A selection of applicable existing strategies is analysed, featuring interpolation-restart and compressed checkpointing for the numerical schemes, in-memory checkpointing, user-level failure mitigation and backup-based methods for the systems. Numerical examples showcase the performance of the techniques in addressing faults, with particular emphasis on iterative solvers for linear systems, a staple of atmospheric fluid flow solvers. The potential impact of these strategies is discussed in relation to current development of numerical weather prediction algorithms and systems towards the exascale. Trade-offs between performance, efficiency and effectiveness of resiliency strategies are analysed and some recommendations outlined for future developments.
The ultimate goal of the Integrated Power, Avionics and Software (iPAS) project is to develop a simulation facility that can be apply to various missions that use common avionics, hardware, and software architecture. The iPAS facility will model several subsystems, the EP4 contribution to the project is to design and build a low fidelity representation of the in-space propulsion system for the iPAS simulation. The system would use a pressurized bottle to provide the gas for the thrusters. Air will be used to perform the simulation to prevent a hazardous environment in the facility. Three cold gas thrusters previously used for the X-38 program will be used for the simulation because they are on hand and available for use. An incremental design-build-test approach will be taken where the X-38 thrusters may be replaced with actual flight thrusters as the flight design is matured. A pressurized system must be designed, built, and tested to reduce the 2,400psi bottle pressure to a reasonable pressure (0-800psig) to minimize the amount of noise created upon thruster activation. Once all the subsystems are completed they will be integrated together for testing.
Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.
NASA is embarking on a new generation of missions to the Moon, known as the Artemis program. The Agency’s new super heavy-lift launch vehicle, the Space Launch System (SLS), is a critical enabling capability for these efforts, which will serve as a proving ground for future crewed expeditions to Mars. SLS is designed to return astronauts to the Moon in the Orion spacecraft and to launch more mass and provide more volume for critical payloads than commercially available vehicles, giving NASA a unique asset for deep space exploration. When performance margin and volume is available, as it is on the first flight, Artemis I (previously Exploration Mission-1), SLS can offer CubeSats access to deep space, beyond Earth’s orbit. The Artemis I flight has 13 6U (14 kg) CubeSats manifested, and the Program is currently accepting proposals for 6U and 12U payloads for the Artemis II flight through the agency’s CubeSat Launch Initiative (CSLI) program. Proposals from U.S.-based payload developers to fly on Artemis II will be accepted through CSLI until November 4, 2019. When ridesharing on SLS deep space missions, CubeSats must demonstrate they will not interfere with primary mission objectives. The 13 Artemis I CubeSats that hail from industry, academia, NASA and its international partners represent an array of exciting deep space science investigations and technology demonstrations that may help inform future Artemis missions. The initial SLS Block 1 vehicle for the Artemis I flight is fully manufactured; several elements are complete and have been delivered to the Exploration Ground Systems (EGS) Program at Kennedy Space Center (KSC), which has responsibility for integrating and launching the SLS and Orion stack. Completed elements of the Artemis I vehicle include the Orion Stage Adapter (OSA), which houses the 13 Artemis I CubeSats. With the Artemis I flight hardware and software nearing completion, work is in progress for the second Block 1 launcher, designated for the crewed Artemis II flight. Hardware is being manufactured for every element of the Artemis II vehicle. In this paper, the author will review the status of the Artemis I vehicle and the payloads manifested for the initial flight. Information on the Secondary Payload Deployment System (SPDS) that the SLS Program provides to payload developers will also be included.
A mission simulation prototype for Distributed Space Systems has been constructed using existing developmental hardware and software testbeds at NASA s Goddard Space Flight Center. A locally distributed ensemble of testbeds, connected through the local area network, operates in real time and demonstrates the potential to assess the impact of subsystem level modifications on system level performance and, ultimately, on the quality and quantity of the end product science data.
This paper provides descriptions of the requirements analysis, hardware development and software development phases of the Control System design for the MOD-5A 7.3 mW Wind Turbine Generator. The system, designed by General Electric Company, Advanced Energy Programs Department, under contract DEN 3-153 with NASA Lewis Research Center and DOE, provides real time regulation of rotor speed by control of both generator torque and rotor torque. A variable speed generator system is used to provide both airgap torque control and reactive power control. The wind rotor is designed with segmented ailerons which are positioned to control blade torque. The central component of the control system, selected early in the design process, is a programmable controller used for sequencing, alarm monitoring, communication, and real time control. Development of requirements for use of aileron controlled blades and a variable speed generator required an analytical simulation that combined drivetrain, tower and blade elastic modes with wind disturbances and control behavior. An orderly two phase plan was used for controller software development. A microcomputer based turbine simulator was used to facilitate hardware and software integration and test.