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 Regolith Advanced Surface Systems Operations Robot (RASSOR) excavator robot is a teleoperated mobility platform with a space regolith excavation capability. This more compact, lightweight design (<50 kg) has counterrotating bucket drums, which results in a net-zero reaction horizontal force due to the self-cancellation of the symmetrical, equal but opposing, digging forces.
System models are often touted as engineering tools that promote better understanding of systems, but these models are typically created during system design. The Ground Data System (GDS) team for the Dawn spacecraft took on a case study to see if benefits could be achieved by starting a model of a system already in operations. This paper focuses on the four steps the team undertook in modeling the Dawn GDS: defining a model structure, populating model elements, verifying that the model represented reality, and using the model to answer system-level questions and simplify day-to-day tasks. Throughout this paper the team outlines our thought processes and the system insights the model provided.
Autonomous control systems provides the ability of self-governance beyond the conventional control system. As the complexity of mechanical and electrical systems increases, there develops a natural drive for developing robust control systems to manage complicated operations. By closing the bridge between conventional automated systems to knowledge based self-awareness systems, nominal control of operations can evolve into relying on safe critical mitigation processes to support any off-nominal behavior. Current research and development efforts lead by the Autonomous Propellant Loading (APL) group at NASA Kennedy Space Center aims to improve cryogenic propellant transfer operations by developing an automated control and health monitoring system. As an integrated systems, the center aims to produce an Autonomous Operations System (AOS) capable of integrating health management operations with automated control to produce a fully autonomous system.
A distributed operations system, the Web Interface for Telescience (WITS), is being developed for use in future planetary lander and rover mission operations.
The notion of using operational scenarios as part of requirements development during mission formulation (Phases A & B) is widely accepted as good system engineering practice. In the context of developing a Mission Operations System (MOS), there are numerous practical challenges to translating that notion into the cost-effective development of a useful set of requirements. These challenges can include such issues as a lack of Project-level focus on operations issues, insufficient or improper flowdown of requirements, flowdown of immature or poor-quality requirements from Project level, and MOS resource constraints (personnel expertise and/or dollars). System engineering theory must be translated into a practice that provides enough structure and standards to serve as guidance, but that retains sufficient flexibility to be tailored to the needs and constraints of a particular MOS or Project. We describe a detailed, scenario-based process for requirements development. Identifying a set of attributes for high quality requirements, we show how the portions of the process address many of those attributes. We also find that the basic process steps are robust, and can be effective even in challenging Project environments.
One of the most challenging tasks in a space science mission is designing the Mission Operations System (MOS). Whereas the focus of the project is getting the spacecraft built and tested for launch, the mission operations engineers must build a system to carry out the science objectives. The completed MOS design is then formally assessed in the many reviews. Once a mission has completed the reviews, the Mission Operation System (MOS) design has been validated to the Functional Requirements and is ready for operations. The design was built based on heritage processes, new technology, and lessons learned from past experience. Furthermore, our operational concepts must be properly mapped to the mission design and science objectives. However, during the course of implementing the science objective in the operations phase after launch, the MOS experiences an evolutional change to adapt for actual performance characteristics. This drives the re-engineering of the MOS, because the MOS includes the flight and ground segments. Using the Spitzer mission as an example we demonstrate how the MOS design evolved for both the prime and extended mission to enhance the overall efficiency for science return. In our re-engineering process, we ensured that no requirements were violated or mission objectives compromised. In most cases, optimized performance across the MOS, including gains in science return as well as savings in the budget profile was achieved. Finally, we suggest a need to better categorize the Operations Phase (Phase E) in the NASA Life-Cycle Phases of Formulation and Implementation
A modular approach for assessing the affects of radiation environments on man in operational systems has been developed. The feasibility of the model has been proved and the practicality has been assessed. It has been applied to one operational system to date and information obtained has been submitted to systems analysts and mission planners for the assessment of man's vulnerability and impact on systems survivability. In addition, the model has been developed so that the radiobiological data can be input to a sophisticated man-machine interface model to properly relate the radiobiological stress with other mission stresses including the effects of a degraded system.
A perspective on safety program management was developed for a complex R&D operating system, such as the NASA-Lewis Research Center. Using a systems approach, hazardous operations are subjected to third-party reviews by designated-area safety committees and are maintained under safety permit controls. To insure personnel alertness, emergency containment forces and employees are trained in dry-run emergency simulation exercises. The keys to real safety effectiveness are top management support and visibility of residual risks.
Ground support real time operating system 360 for manned spaceflight, discussing system features and performance
A perspective on safety program management has been developed for a complex R&D operating system, such as the NASA-Lewis Research Center. Using a systems approach, hazardous operations are subjected to third-party reviews by designated area safety committees and are maintained under safety permit controls. To insure personnel alertness, emergency containment forces and employees are trained in dry-run emergency simulation exercises. The keys to real safety effectiveness are top management support and visibility of residual risks.
Specific modifications in the Disk Operational System Unified Series to insure the relocatability of programs stored permanently in the core image library is described. A self-relocating method for loading programs into the working memory with re-editing all the programs recorded in the core image library is presented. The modified linkage editor can be included in a relocation dictionary containing data about each address constant at the assembly stage at the request of the programmer. The relocation dictionary increases the dimension of the RL-phase in comparison with the dimension of this same phase when edited by the standard method, making possible the creation of multiphase program complexes. Generation and use of the modified system using Assembly language is described. An example of the use of the system is given, and limitations of the use of the relocatable programs in the modified system are outlined.
NASA-Langley's Advanced Transport Operating Systems Program employs a heavily instrumented, B 737-100 as its Transport Systems Research Vehicle (TRSV). The TRSV has been used during the demonstration trials of the Time Reference Scanning Beam Microwave Landing System (TRSB MLS), the '4D flight-management' concept, ATC data links, and airborne windshear sensors. The credibility obtainable from successful flight test experiments is often a critical factor in the granting of substantial commitments for commercial implementation by the FAA and industry. In the case of the TRSB MLS, flight test demonstrations were decisive to its selection as the standard landing system by the ICAO.
This study was undertaken to determine the single-event functional interrupt (SEFI) susceptibility on different Linux operating system configurations. The device-under-test (DUT) was the Xilinx Zynq-7020 SoC on the TUL PYNQ-Z2 board. The device was monitored for kernel panics or hangs, classified as SEFIs, to observe any differences in the SEFI cross sections between operating system configurations. The primary purpose of this experiment was to observe if the number of drivers installed in a Linux system affects its overall execution reliability.
Initial results of the integrated AR POST conducted by Boeing at Marshall Space Flight Center in 1992 are presented. The three baselined ECLSS Man Tended Capability AR assemblies were integrated and operated in a closed door chamber in which the internal atmosphere was monitored. The test provides a prerequisite checkout of the AR subsystem in preparation for longer duration tests in which the AR subsystem will be integrated with the Water Recovery Management subsystem. The integrated AR POST will serve as an early test bed to evaluate the integration of the space station ECLSS AR subsystem during design maturation.
Environment-based disasters, such as wildfire, can cause substantial loss of life and loss of property and are costing billions of dollars annually. Existing disaster response operations are complex, with many challenges. The aim of the Scalable Traffic management for Emergency Response Operations (STEReO) system is to demonstrate the application of technologies that will enable small, low-altitude Unmanned Aerial System operations to safely take place in the airspace above a disaster event, increasing the effectiveness of the response. As a first step, the project aims to build a small prototype to demonstrate and test the core functions of this system based on user needs and requirements that were gathered from experts in the field during discussions and walkthroughs.
This document describes the software created for the Sperry Microprocessor Color Display System used for the Advanced Transport Operating Systems (ATOPS) project on the Transport Systems Research Vehicle (TSRV). The software delivery known as the 'baseline display system', is the one described in this document. Throughout this publication, module descriptions are presented in a standardized format which contains module purpose, calling sequence, detailed description, and global references. The global reference section includes procedures and common variables referenced by a particular module. The system described supports the Research Flight Deck (RFD) of the TSRV. The RFD contains eight cathode ray tubes (CRTs) which depict a Primary Flight Display, Navigation Display, System Warning Display, Takeoff Performance Monitoring System Display, and Engine Display.
The flight software developed for the Flight Management/Flight Controls (FM/FC) MicroVAX computer used on the Transport Systems Research Vehicle for Advanced Transport Operating Systems (ATOPS) research is described. The FM/FC software computes navigation position estimates, guidance commands, and those commands issued to the control surfaces to direct the aircraft in flight. Various modes of flight are provided for, ranging from computer assisted manual modes to fully automatic modes including automatic landing. A high-level system overview as well as a description of each software module comprising the system is provided. Digital systems diagrams are included for each major flight control component and selected flight management functions.
The Marshall Space Flight Center (MSFC) Ground Systems Department (GSD) recently undertook an architecture change in the product line that serves the ISS program. As a result, the architecture tradeoffs between data system product lines that serve remote users versus those that serve control center flight control teams were explored extensively. This paper describes the resulting architecture that will be used in the ISS payloads program, and the resulting functional breakdown of the products that support that architecture. It also describes the lessons learned from the path that was followed, as a migration of products cause the need to reevaluate the allocation of functions across the architecture. The result is a set of innovative ground system solutions that is scalable so it can support facilities of wide-ranging sizes, from a small site up to large control centers. Effective use of system automation, custom components, design optimization for data management, data storage, data transmissions, and advanced local and wide area networking architectures, plus the effective use of Commercial-Off-The-Shelf (COTS) products, provides flexible Remote Ground System options that can be tailored to the needs of each user. This paper offers a description of the efficiency and effectiveness of the Ground Systems architectural options that have been implemented, and includes successful implementation examples and lessons learned.