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.
Topics covered in the workshop included studies and experiments conducted in the Software Engineering Laboratory (SEL), a cooperative effort of NASA Goddard Space Flight Center, the University of Maryland, and Computer Sciences Corporation; software models; software products; and software tools.
Flight test results have been obtained which demonstrate the feasibility and desirability of using knowledge-based systems architectures for flight test investigations of primary flight display information management-related issues. LISP-based software was used for real-time operation of the primary flight display. The two integrated knowledge-based systems designed to control the primary flight displays were implemented aboard a NASA-Langley B-737. The programmer is noted to be capable of more easily developing initial systems via the present method than with more conventional techniques.
The information presented in this Acceptance Test Plan document shows the current status of the General Mission Analysis Tool (GMAT). GMAT is a software system developed by NASA Goddard Space Flight Center (GSFC) in collaboration with the private sector. The GMAT development team continuously performs acceptance tests in order to verify that the software continues to operate properly after updates are made. The GMAT Development team consists of NASA/GSFC Code 583 software developers, NASA/GSFC Code 595 analysts, and contractors of varying professions. GMAT was developed to provide a development approach that maintains involvement from the private sector and academia, encourages collaborative funding from multiple government agencies and the private sector, and promotes the transfer of technology from government funded research to the private sector. GMAT contains many capabilities, such as integrated formation flying modeling and MATLAB compatibility. The propagation capabilities in GMAT allow for fully coupled dynamics modeling of multiple spacecraft, in any flight regime. Other capabilities in GMAT inclucle: user definable coordinate systems, 3-D graphics in any coordinate system GMAT can calculate, 2-D plots, branch commands, solvers, optimizers, GMAT functions, planetary ephemeris sources including DE405, DE200, SLP and analytic models, script events, impulsive and finite maneuver models, and many more. GMAT runs on Windows, Mac, and Linux platforms. Both the Graphical User Interface (GUI) and the GMAT engine were built and tested on all of the mentioned platforms. GMAT was designed for intuitive use from both the GUI and with an importable script language similar to that of MATLAB.
Non-deterministic systems often rely upon neural network (NN) technology to "lean" to manage flight systems under controlled conditions using carefully chosen training sets. How can these adaptive systems be certified to ensure that they will become increasingly efficient and behave appropriately in real-time situations? The bulk of Independent Verification and Validation (IV&V) research of non-deterministic software control systems such as Adaptive Flight Controllers (AFC's) addresses NNs in well-behaved and constrained environments such as simulations and strict process control. However, neither substantive research, nor effective IV&V techniques have been found to address AFC's learning in real-time and adapting to live flight conditions. Adaptive flight control systems offer good extensibility into commercial aviation as well as military aviation and transportation. Consequently, this area of IV&V represents an area of growing interest and urgency. ISR proposes to further the current body of knowledge to meet two objectives: Research the current IV&V methods and assess where these methods may be applied toward a methodology for the V&V of Neural Network; and identify effective methods for IV&V of NNs that learn in real-time, including developing a prototype test bed for IV&V of AFC's. Currently. no practical method exists. lSR will meet these objectives through the tasks identified and described below. First, ISR will conduct a literature review of current IV&V technology. TO do this, ISR will collect the existing body of research on IV&V of non-deterministic systems and neural network. ISR will also develop the framework for disseminating this information through specialized training. This effort will focus on developing NASA's capability to conduct IV&V of neural network systems and to provide training to meet the increasing need for IV&V expertise in such systems.
A candidate onboard space navigation filter demonstrated excellent performance (less than 8 meter level RMS semi-major axis accuracy) in performing orbit determination of a low-Earth orbit Explorer satellite using single-frequency real GPS data. This performance is significantly better than predicted by other simulation studies using dual-frequency GPS data. The study results revealed the significance of two new modeling approaches evaluated in the work. One approach introduces a single-frequency ionospheric correction through pseudo-range and phase range averaging implementation. The other approach demonstrates a precise axis-dependent characterization of dynamic sample space uncertainty to compute a more accurate Kalman filter gain. Additionally, this navigation filter demonstrates a flexibility to accommodate both perturbational dynamic and observational biases required for multi-flight phase and inhomogeneous application environments. This paper reviews the potential application of these methods and the filter structure to terrestrial vehicle and positioning applications. Both the single-frequency ionospheric correction method and the axis-dependent state noise modeling approach offer valuable contributions in cost and accuracy improvements for terrestrial GPS receivers. With a modular design approach to either 'plug-in' or 'unplug' various force models, this multi-flight phase navigation filter design structure also provides a versatile GPS navigation software engine for both atmospheric and exo-atmospheric navigation or positioning use, thereby streamlining the flight phase or application-dependent software requirements. Thus, a standardized GPS navigation software engine that can reduce the development and maintenance cost of commercial GPS receivers is now possible.
Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.
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.
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.
A microprocessor-based general purpose ground support equipment for electronic systems was developed. The hardware and software are designed to permit diverse applications in support of aircraft flight systems and simulation facilities. The implementation of the hardware, the structure of the software, describes the application of the system to an ongoing research aircraft project are described.
Advanced fighter technologies are evolving into highly complex systems. Flight controls are being integrated with advanced avionics to achieve a total system. The advanced fighter technology integration (AFTI) F-16 aircraft is an example of a highly complex digital flight control system integrated with advanced avionics and cockpit. The architecture of these new systems involves several general issues. The use of dissimilar backup modes if the primary system fails requires the designer to trade off system simplicity and capability. This tradeoff is evident in the AFTI/F-16 aircraft with its limited stability and fly-by-wire digital flight control systems. In case of a generic software failure, the backup or normal mode must provide equivalent envelope protection during the transition to degraded flight control. The complexity of systems like the AFTI/F-16 system defines a second design issue, which can be divided into two segments: the effect on testing, and the pilot's ability to act correctly in the limited time available for cockpit decisions. The large matrix of states possible with the AFTI/F-16 flight control system illustrates the difficulty of both testing the system and choosing real-time pilot actions.
It is pointed out that ground tests, which involve end-to-end checks of various subsystems often by stimulating an input device and examining the resultant effect, do not exercise dynamically all subsystem interactions encountered during a real flight. The development and implementation of the Dynamic Integrated Test (DIT) for the Space Transportation System, patterned on the ASIST (Avionics System Integration Self Test) concept, are examined. It is noted that the complete hardware-software data paths which are utilized in flight simply do not exist until the vehicle is assembled. The integrated test is considered necessary in order to verify the integrity of these paths, that is, to establish that proper connections have been made, that correct polarity is maintained, and that no unexpected interference is generated. As a result of four tests carried out on the Space Transportation System, hardware and software problems, both on-board the vehicle and within the launch support complex, were identified and resolved. Significant return was also realized in the training of the launch and flight crews.
The research and work conducted on the development of a testbed for a display and control panel for the Flight Telerobotic Servicer (FTS) are presented. Research was conducted on both software and hardware needed to control the FTS. A breadboard was constructed and placed into a mockup of the aft station of the Orbiter spacecraft. This breadboard concept was then evaluated using a computer graphics representation of the Tinman FTS. Extensive research was conducted on the software requirements and implementation. The hardware selected for the breadboard was 'flight like' and in some cases fit and function evaluated. The breadboard team studied some of the concepts without pursuing in depth their impact on the Orbiter or other missions. Assumptions are made concerning payload integration.
The rationale and mechanization of sensor fault tolerance based on analytical redundancy principles are described. The concept involves the substitution of software procedures, such as an observer algorithm, to supplant additional hardware components. The observer synthesizes values of sensor states in lieu of their direct measurement. Such information can then be used, for example, to determine which of two disagreeing sensors is more correct, thus enhancing sensor fault survivability. Here a stability augmentation system is used as an example application, with required modifications being made to a quadruplex digital flight control system. The impact on software structure and the resultant revalidation effort are illustrated as well. Also, the use of an observer algorithm for wind gust filtering of the angle-of-attack sensor signal is presented.
The term "flight envelope" is used to refer to the boundaries of aircraft loading and flight conditions within which operation of the aircraft is satisfactory, and beyond which some aspect becomes unacceptable. This flight envelope represents, in fact, the limiting conditions arising from a matrix of inter-related flight envelopes covering the appropriate variables. Thus, for each loading (i.e., external stores configuration and its associated range of weight and center of gravity (c.g.) position) and aircraft configuration (i.e., position of undercarriage (u/c), flaps, slats, etc.), the envelopes of airspeed versus altitude, airspeed versus load factor, angle of attack versus angle of sideslip, etc., must be investigated to establish the limits within which all aspects such as handling qualities, engine behavior, structural loads, etc., remain acceptable. Flight testing of new or derivative aircraft models is carried out with the initial purpose of defining a flight envelope which is, first and foremost, safe and secondarily, which enables the effective use of the vehicle for its intended purpose. Flight testing occurs only after numerous reviews of the design and review of results from ground tests and predictions of flight characteristics in such areas as structures, aerodynamics, stability and control, flight controls (particularly fly-by-wire control systems, propulsion, etc.). Accordingly, opening and expanding the envelope is a task that must be approached cautiously, systematically, and with coordination and cooperation of the many disciplines involved in the design and test of an airplane. (Sections 8 and 10 cover test planning and safety of flight considerations, respectively). The fundamental tenet in establishing a flight envelope via flight test is risk reduction. This is reflected in the typical sequence of events leading to initial flight test - design reviews (both hardware and software), then ground test involving singular disciplines (windtunnel tests for aerodynamics, structurally loading the wing/fuselage/nacelle on a ground test article with loads anticipated to occur in flight, flight control system control law checkout, propulsion test cell runs and/or flying test bed tests, etc.), and then ground tests involving multi-disciplines (See Section 9). Only after these have been accomplished will an initial, limited, low-risk, flight envelope be established. The limited envelope will typically be in the middle of the projected final flight envelope. Subsequent flight tests will then be devoted to expanding the initial envelope by operating the airplane at increasing ranges - representing increasing risk - of engine operation, airspeeds both fast and slow, altitude, load factor both above and below 1g, centers of gravity (fore and aft), and with system/subsystem failures. Whether flight tests are to define a flight envelope on a new model airplane with the attendant new airframe, new engine(s), and new subsystems (hydraulics, pressurization, etc.), or on an airplane involving only a few of these areas such as new engines in an old airframe, the fundamental approach to establishing an envelope is the same.
A status report is presented on facilities and planned operations at the Kennedy Space Center with reference to Space Shuttle launch activities. The facilities are essentially complete, with all new construction and modifications to existing buildings almost finished. Some activity is still in progress at Pad A and on the Mobile Launcher due to changes in requirements but is not expected to affect the launch schedule. The installation and testing of the ground checkout equipment that will be used to test the flight hardware is now in operation. The Launch Processing System is currently supporting the development of the applications software that will perform the testing of this flight hardware.
Successfully executing proximity operations in space, such as docking or in-orbit servicing, requires sophisticated spacecraft design that accounts for induced environments. As a chaser vehicle’s attitude control thrusters fire, they create rarefied plumes that can impact the target vehicle, with the potential to overload components, exceed thermal limits, and spin the target vehicle out of control. High-fidelity simulations of the thruster plume impingement environment require the direct simulation Monte Carlo (DSMC) method, but DSMC is too computationally expensive to simulate proximity operations that involve thousands of thruster firings. For this analysis to be tractable, engineering models of the plume flowfield and impingement events are used to simulate these trajectories [1]. Currently, on-orbit plume impingement environments are modeled through an inefficient open-loop analysis cycle where the vehicle’s flight controller and plume impingement teams iterate on the trajectories until they pass the target vehicle’s plume requirements. As complex on-orbit missions evolve and become more frequent, lengthy design cycles will become operational bottlenecks. To address this gap, this work develops an advanced plume impingement module capable of operating at real-time scale that can be integrated with existing mission planning tools and onboard flight systems. The plume module leverages state-of-the-art plume simulation techniques [2] to deliver fast, physics-based impingement predictions in a software architecture that can be tailored to diverse proximity operations scenarios. A prototype of this plume impingement module is built to demonstrate the feasibility of real-time performance. This prototype completes plume impingement calculations in microseconds per target geometry mesh point. The software serves as a foundational capability for plume-aware trajectory design, operational risk assessment, and future autonomous decision-making systems.
Work being accomplished to develop a real-time, piloted simulation of a helicopter using the vertical motion simulator at NASA Ames is discussed. The trajectory generation algorithm and the flight path controller are described, and the software integration of the entire terrain following/terrain avoidance (TF/TA) system is discussed. Real-time simulation requirements and the unique features of applying TF/TA system to helicopter flight are summarized. Initial results indicate that the system is satisfactory for automatic, low level TF/TA helicopter flight.
Work being accomplished to develop a real-time, piloted simulation of a helicopter using the vertical motion simulator at NASA Ames is discussed. The trajectory generation algorithm and the flight path controller are described, and the software integration of the entire terrain following/terrain avoidance (TF/TA) system is discussed. Real-time simulation requirements and the unique features of applying TF/TA system to helicopter flight are summarized. Initial results indicate that the system is satisfactory for automatic, low level TF/TA helicopter flight.