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.
The tasks are defined required to design, develop produce, and field support a shuttle mission simulator for training crew members and ground support personnel. The requirements for program management, control, systems engineering, design and development are discussed along with the design and construction standards, software design, control and display, communication and tracking, and systems integration.
The bibliography contains 368 abstract citations of reports, journal articles, and other documents concerned with the engineering and theoretical aspects of design, construction, evaluation, testing, operation, and performance of aircraft (including aircraft engines) and associated components, equipment, and systems. Research and development in aerodynamics, aeronautics, and ground support equipment are also treated. Subject, personal, and contract number indexes are included for ease of access.
An analysis of the requirements for the Earth Observatory Satellite (EOS) system specifications is presented. The analysis consists of requirements obtained from existing documentation and those derived from functional analysis. The requirements follow the hierarchy of program, mission, system, and subsystem. The code for designating specific requirements is explained. Among the subjects considered are the following: (1) the traffic model, (2) space shuttle related performance, (3) booster related performance, (4) the data collection system, (5) spacecraft structural tests, and (6) the ground support requirements.
Consumables models required for the mission planning and scheduling function are formulated. The relation of the models to prelaunch, onboard, ground support, and postmission functions for the space transportation systems is established. Analytical models consisting of an orbiter planning processor with consumables data base is developed. A method of recognizing potential constraint violations in both the planning and flight operations functions, and a flight data file storage/retrieval of information over an extended period which interfaces with a flight operations processor for monitoring of the actual flights is presented.
Applications of automation, robotics, and machine intelligence systems (ARAMIS) to space activities, and their related ground support functions are studied so that informed decisions can be made on which aspects of ARAMIS to develop. The space project breakdowns, which are used to identify tasks ('functional elements'), are described. The study method concentrates on the production of a matrix relating space project tasks to pieces of ARAMIS.
Applications of automation, robotics, and machine intelligence systems (ARAMIS) to space activities and their related ground support functions are studied, so that informed decisions can be made on which aspects of ARAMIS to develop. The specific tasks which will be required by future space project tasks are identified and the relative merits of these options are evaluated. The ARAMIS options defined and researched span the range from fully human to fully machine, including a number of intermediate options (e.g., humans assisted by computers, and various levels of teleoperation). By including this spectrum, the study searches for the optimum mix of humans and machines for space project tasks.
The Ground Software Maintenance Facility (GSMF) is designed to support development and maintenance of spacelab ground support software. THE GSMF consists of a Perkin Elmer 3250 (Host computer) and a MITRA 125s (ATE computer), with appropriate interface devices and software to simulate the Electrical Ground Support Equipment (EGSE). This document is presented in three sections: (1) GSMF Overview; (2) Software Structure; and (3) Fault Isolation Capability. The overview contains information on hardware and software organization along with their corresponding block diagrams. The Software Structure section describes the modes of software structure including source files, link information, and database files. The Fault Isolation section describes the capabilities of the Ground Computer Interface Device, Perkin Elmer host, and MITRA ATE.
In an earlier paper [1] examples of agent technology in a NASA context were presented. Both groundbased and space-based applications were addressed. This paper continues the discussion of one aspect of the Goddard Space Flight Center's continuing efforts to develop a community of agents that can support both ground-based and space-based systems autonomy. The paper focuses on an approach to agent-community modeling based on the theory of viable systems developed by Stafford Beer. It gives the status of an initial attempt to capture some of the agent-community behaviors in a viable system context. This paper is expository in nature and focuses on a discussion of the modeling of some of the underlying concepts and infrastructure that will serve as the basis of more detailed investigative work into the behavior of agent communities. The paper is organized as follows. First, a general introduction to agent community requirements is presented. Secondly, a brief introduction to the cybernetic concept of a viable system is given. This concept forms the foundation of the modeling approach. Then the concept of an agent community is modeled in the cybernetic context.
With rapid technology changes and new and improved development techniques, it becomes extremely difficult to try to add capabilities to existing ground systems without wanting to replace the entire system. Replacing entire systems is not usually cost effective so there is a need to be able to slowly improve systems without long development times that introduce risk due to large amounts of change. The Marshall Space Flight Center s (MSFC) Payload Operations Integration Center (POIC) ground system provides command, telemetry, and payload planning systems in support of the International Space Station. Our systems have continuously evolved with technology changes due to hardware end of life issues, and also due to user requirement changes. As changes have been implemented, we have tried to take advantage of some of the latest technologies while at the same time maintaining certain legacy capabilities that are not cost affective to replace. One of our biggest challenges is to integrate all of these implementations into a single system that is usable, maintainable, and scalable. Another challenge is to provide access to our tools in such a way that users are not aware of all the various implementation methods and tools being used. This approach not only makes our system much more usable, it allows us to continue to migrate capabilities and to add capabilities without impacting system usability. This paper will give an overview of the tools used for MSFC ISS payload operations and show an approach for integrating various technologies into a single environment that is maintainable, flexible, usable, cost effective, and that meets user needs.
The Radio Frequency Health Node (RFHN) wireless sensor system differs from other wireless sensor systems in ways originally intended to enhance utility as an instrumentation system for a spacecraft. The RFHN can also be adapted to use in terrestrial applications in which there are requirements for operational flexibility and integrability into higher-level instrumentation and data acquisition systems. As shown in the figure, the heart of the system is the RFHN, which is a unit that passes commands and data between (1) one or more commercially available wireless sensor units (optionally, also including wired sensor units) and (2) command and data interfaces with a local control computer that may be part of the spacecraft or other engineering system in which the wireless sensor system is installed. In turn, the local control computer can be in radio or wire communication with a remote control computer that may be part of a higher-level system. The remote control computer, acting via the local control computer and the RFHN, cannot only monitor readout data from the sensor units but can also remotely configure (program or reprogram) the RFHN and the sensor units during operation. In a spacecraft application, the RFHN and the sensor units can also be configured more nearly directly, prior to launch, via a serial interface that includes an umbilical cable between the spacecraft and ground support equipment. In either case, the RFHN wireless sensor system has the flexibility to be configured, as required, with different numbers and types of sensors for different applications. The RFHN can be used to effect realtime transfer of data from, and commands to, the wireless sensor units. It can also store data for later retrieval by an external computer. The RFHN communicates with the wireless sensor units via a radio transceiver module. The modular design of the RFHN makes it possible to add radio transceiver modules as needed to accommodate additional sets of wireless sensor units. The RFHN includes a core module that performs generic computer functions, including management of power and input, output, processing, and storage of data. In a typical application, the processing capabilities in the RFHN are utilized to perform preprocessing, trending, and fusion of sensor data. The core module also serves as the unit through which the remote control computer configures the sensor units and the rest of the RFHN.
This paper presents a ground system architecture to service future NASA decadal missions and in particular, the high rate science data downlinks, by evolving EDOS current infrastructure and upgrading high rate network lines. The paper will also cover EDOS participation to date in formulation and operations concepts for the respective missions to understand the particular mission needs and derived requirements such as data volumes, downlink rates, data encoding, and data latencies. Future decadal requirements such as onboard data recorder management and file protocols drive the need to emulate these requirements within the ground system. The EDOS open system modular architecture is scalable to accommodate additional missions using the current sites antennas and future sites as well and meet the data security requirements and fulfill mission's objectives
In 2017, the James Webb Space Telescope (JWST) underwent functional testing and optical metrology verification of the combined Optical Telescope Element and Integrated Science Instrument Module (OTIS) under cryogenic vacuum conditions in Chamber A at the Johnson Space Center. Maintaining flight-like thermal boundary conditions was a critical requirement for optical testing and required unique and challenging Ground Support Equipment (GSE) design solutions. Two such GSE systems, the Integrated Science Instrument Module (ISIM) Precool Straps and the Hardpoint Struts were direct conduction interfaces to the flight hardware. Hardware safety during cooldown required detailed design of their conductivity, and thermal balance testing required "zero-Q" (0-Q) heater implementation to bring the heat flow to zero, thereby cutting off these non-flight conductive links after operating temperatures were achieved. This paper describes the design considerations and approach implemented to achieve the required flight hardware cool down and return to ambient conditions, ensure flight hardware safety, and minimize the non-flight-like heat flows to or from the observatory during cryo-stable testing.
In 2017, the James Webb Space Telescope (JWST) underwent functional testing and optical metrology verification of the combined Optical Telescope Element and Integrated Science Instrument Module (OTIS) under cryogenic vacuum conditions in Chamber A at the Johnson Space Center. Maintaining flight-like thermal boundary conditions was a critical requirement for optical testing and required unique and challenging Ground Support Equipment (GSE) design solutions. Two such GSE systems, the Integrated Science Instrument Module (ISIM) Precool Straps and the Hardpoint Struts were direct conduction interfaces to the flight hardware. Hardware safety during cooldown required detailed design of their conductivity, and thermal balance testing required zero-Q (0-Q) heater implementation to bring the heat flow to zero, thereby cutting off these non-flight conductive links after operating temperatures were achieved. This paper describes the design considerations and approach implemented to achieve the required flight hardware cool down and return to ambient conditions, ensure flight hardware safety, and minimize the non-flight-like heat flows to or from the observatory during cryo-stable testing.
This paper presents a case study of the knowledge engineering process employed to support the Link Monitor & Control Operator Assistant (LMCOA). The LMCOA is a prototype system which automates equipment used to support space-ground communication with deep space spacecraft in NASA's Deep Space Network (DSN). The primary knowledge base in the LMCOA is the Temporal Dependency Network (TDN). The paper provides a brief background on the DSN, and describes the evolution of the TDN and supporting knowledge bases, the process used for knowledge engineering, and an analysis of the successes--and problems--of the knowledge engineering effort.
Activity Planning with Resources for the Exploration of Space (APRES) is a mixed-initiative mission planning system for ground operations. APRES has been designed to support multi-spacecraft missions. The APRES Interface is browser-based and includes a plan editor, a timeline plan display, a temporal constraint editor, display of the state and numeric chronicles, and a violation resolution manager. Automation support is supplied by the APRES Service, which includes components that provide the following capabilities:(1) plan simulation, which determines the state and numeric chronicles (values of the model variables over time) and determines when "processes" are triggered and terminated based on world states in the execution trace, (2) violation detection of constraints and flight rules encoded in the domain model, and of the temporal constraints created by the user, (3) violation resolution suggestions as to how to fix the plan's violations via rescheduling. The user controls when and how to utilize the automation support. Demo video included with paper, runtime 8:54 in color with sound.
The Mars 2020 Rover mission is using automated scheduling in two capacities. As of March 2021 a ground-based scheduler automatically schedules rover wake/sleep and preheats to support Mars 2020 daily operations. Included in the ground system is an explainable scheduling tool that allows users in-sight into the schedule developed by the automated scheduler. An onboard scheduler that will allow the rover autonomously better account for variations in execution is in development for use later in the mission.
The Cockpit Interface Control Document defines the hardware interfaces between the X-57 cockpit and subsystems. It provides locational and operational information in support of ground and flight operations with details on controls and displays that include Modes of Operation, Start-Up and Shut- Down Sequence diagrams and captures the current state of the MOD II Avionics Power Architecture. There is also preliminary information of the MOD III and MOD IV configurations. Microsoft PowerPoint was chosen for the document as early development required frequent meetings with multiple customers including aircraft operators (pilots), ground operations, support contractors and power, instrumentation, and human systems integration engineers and PowerPoint enabled presentations that could be quickly modified based on customer and developer interaction. One of the driving requirements for the cockpit design was to keep the left side panel as close the stock Tecnam panel as possible to reduce the failure risk of flight critical indicators. The original annunciator panel in the left side panel was modified to alert the pilot to failures in critical X-57 subsystems and an operator audio alert capability was added for these subsystems. Power-Up switches for the aircraft low voltage 13.8 VDC systems are located at the bottom of the left side panel and center panel, the same location as the stock Tecnam 13.8 VDC switches. The switches for energizing the high voltage system were located in the overhead panel to reduce the risk of inadvertently energizing the high voltage system during the low voltage power-up sequence. The Cruise Motor ARM switches were also located in the overhead panel and correspond to the same location as the stock Tecnam ignition switches. The stock Tecnam throttle levers and prop pitch levers were retained for the X-57. The throttle levers were renamed torque levers since they controlled the commanded torque to the cruise motors. The prop pitch levers provide a commanded RPM signal to an electronic prop pitch controller. X-57 specific displays, located in the right-side panel, are driven by dedicated sensors that monitor right and left side cruise motor RPM, right and left high voltage “Traction Bus” A and B (voltage, current and power) and the Avionics Bus DC converters (A and B) voltage and current. An X-57 Multi-Function Display (MFD) located in the center panel displays CAN Bus parameters. CAN Bus architecture is not certified for flight so these displays could not be used for safety critical information but were designed to be used for test point information only.
The Super Strypi Navigation, Guidance & Control Software is a real-time implementation of the navigation, guidance and control algorithms designed to deliver a payload to a desired orbit for the rail launched Super Strypi launch vehicle. The software contains all flight control algorithms required from pre-launch until orbital insertion. The flight sequencer module calls the NG&C functions at the appropriate times of flight. Additional functionality includes all the low level drivers and I/O for communicating to other systems within the launch vehicle and to the ground support equipment. The software is designed such that changes to the launch location and desired orbit can be changed without recompiling the code.