Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Integrated Operations”

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 973 records · Page 54

NEEMO 18-20: Analog Testing for Mitigation of Communication Latency During Human Space Exploration

NASA Extreme Environment Mission Operations (NEEMO) is an underwater spaceflight analog that allows a true mission-like operational environment and uses buoyancy effects and added weight to simulate different gravity levels. Three missions were undertaken from 2014-2015, NEEMO's 18-20. All missions were performed at the Aquarius undersea research habitat. During each mission, the effects of communication latencies on operations concepts, timelines, and tasks were studied. METHODS: Twelve subjects (4 per mission) were weighed out to simulate near-zero or partial gravity extravehicular activity (EVA) and evaluated different operations concepts for integration and management of a simulated Earth-based science team (ST) to provide input and direction during exploration activities. Exploration traverses were preplanned based on precursor data. Subjects completed science-related tasks including pre-sampling surveys, geologic-based sampling, and marine-based sampling as a portion of their tasks on saturation dives up to 4 hours in duration that were designed to simulate extravehicular activity (EVA) on Mars or the moons of Mars. One-way communication latencies, 5 and 10 minutes between space and mission control, were simulated throughout the missions. Objective data included task completion times, total EVA times, crew idle time, translation time, ST assimilation time (defined as time available for ST to discuss data/imagery after data acquisition). Subjective data included acceptability, simulation quality, capability assessment ratings, and comments. RESULTS: Precursor data can be used effectively to plan and execute exploration traverse EVAs (plans included detailed location of science sites, high-fidelity imagery of the sites, and directions to landmarks of interest within a site). Operations concepts that allow for pre-sampling surveys enable efficient traverse execution and meaningful Mission Control Center (MCC) interaction across communication latencies and can be done with minimal crew idle time. Imagery and contextual information from the EVA crew that is transmitted real-time to the intravehicular (IV) crewmember(s) can be used to verify that exploration traverse plans are being executed correctly. That same data can be effectively used by MCC (across comm latency) to provide meaningful feedback and instruction to the crew regarding sampling priorities, additional tasks, and changes to the EVA timeline. Text / data capabilities are preferred over voice capabilities between MCC and IV when executing exploration traverse plans over communication latency.

Chappell, Steven P.↗

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗

Analog Testing of Operations Concepts for Mitigation of Communication Latency During Human Space Exploration

OBJECTIVES: NASA Extreme Environment Mission Operations (NEEMO) is an underwater spaceflight analog that allows a true mission‐like operational environment and uses buoyancy effects and added weight to simulate different gravity levels. Three missions were undertaken from 2014‐2015, NEEMO's 18‐20. All missions were performed at the Aquarius undersea research habitat. During each mission, the effects of varying operations concepts and tasks type and complexity on representative communication latencies associated with Mars missions were studied. METHODS: 12 subjects (4 per mission) were weighed out to simulate near‐zero or partial gravity extravehicular activity (EVA) and evaluated different operations concepts for integration and management of a simulated Earth‐based science backroom team (SBT) to provide input and direction during exploration activities. Exploration traverses were planned in advance based on precursor data collected. Subjects completed science‐related tasks including presampling surveys, geologic‐based sampling, and marine‐based sampling as a portion of their tasks on saturation dives up to 4 hours in duration that were to simulate extravehicular activity (EVA) on Mars or the moons of Mars. One‐way communication latencies, 5 and 10 minutes between space and mission control, were simulated throughout the missions. Objective data included task completion times, total EVA times, crew idle time, translation time, SBT assimilation time (defined as time available for SBT to discuss data/imagery after it has been collected, in addition to the time taken to watch imagery streaming over latency). Subjective data included acceptability, simulation quality, capability assessment ratings, and comments. RESULTS: Precursor data can be used effectively to plan and execute exploration traverse EVAs (plans included detailed location of science sites, high‐fidelity imagery of the sites, and directions to landmarks of interest within a site). Operations concepts that allow for presampling surveys enable efficient traverse execution and meaningful Mission Control Center (MCC) interaction across long communication latencies and can be done with minimal crew idle time. Imagery and information from the EVA crew that is transmitted real‐time to the intravehicular (IV) crewmember(s) can be used to verify that exploration traverse plans are being executed correctly. That same data can be effectively used by MCC (across comm latency) to provide further instructions to the crew from a SBT on sampling priorities, additional tasks, and changes to the plan. Text / data capabilities are preferred over voice capabilities between MCC and IV when executing exploration traverse plans over communication latency. Autonomous crew planning tools can be effective at modifying existing plans if the objectives and constraints are clearly defined.

Chappell, Steven P.↗

Second-Generation Six-Limbed Experimental Robot

The figure shows the LEMUR II - the second generation of the Limbed Excursion Mechanical Utility Robot (LEMUR), which was described in "Six-Legged Experimental Robot" (NPO-20897), NASA Tech Briefs, Vol. 25, No. 12 (December 2001), page 58. The LEMUR II incorporates a number of improvements, including new features, that extend its capabilities beyond those of its predecessor, which is now denoted the LEMUR I. To recapitulate: the LEMUR I was a six-limbed robot for demonstrating robotic capabilities for assembly, maintenance, and inspection. The LEMUR I was designed to be capable of walking autonomously along a truss structure toward a mechanical assembly at a prescribed location and to perform other operations. The LEMUR I was equipped with stereoscopic video cameras and image-data-processing circuitry for navigation and mechanical operations. It was also equipped with a wireless modem, through which it could be commanded remotely. Upon arrival at a mechanical assembly, the LEMUR I would perform simple mechanical operations with one or both of its front limbs. It could also transmit images to a host computer. Each of the six limbs of the LEMUR I was operated independently. Each of the four rear limbs had three degrees of freedom (DOFs), while each of the front two limbs had four DOFs. The front two limbs were designed to hold, operate, and/or be integrated with tools. The LEMUR I included an onboard computer equipped with an assortment of digital control circuits, digital input/output circuits, analog-to-digital converters for input, and digital-to-analog (D/A) converters for output. Feedback from optical encoders in the limb actuators was utilized for closed-loop microcomputer control of the positions and velocities of the actuators. The LEMUR II incorporates the following improvements over the LEMUR I: a) The drive trains for the joints of the LEMUR II are more sophisticated, providing greater torque and accuracy. b) The six limbs are arranged symmetrically about a hexagonal body platform instead of in straight lines along the sides. This symmetrical arrangement is more conducive to omnidirectional movement in a plane. c) The number of degrees of freedom of each of the rear four limbs has been increased by one. Now, every limb has four degrees of freedom: three at the hip (or shoulder, depending on one s perspective) and one at the knee (or elbow, depending on one s perspective). d) Now every limb (instead of only the two front limbs) can perform operations. For this purpose, each limb is tipped with an improved quick-release mechanism for swapping of end-effector tools. e) New end-effector tools have been developed. These include an instrumented rotary driver that accepts all tool bits that have 0.125-in. (3.175-mm)-diameter shanks, a charge-coupled-device video camera, a super bright light-emitting diode for illuminating the work area of the robot, and a generic collet tool that can be quickly and inexpensively modified to accept any cylindrical object up to 0.5 in. (12.7 mm) in diameter. f) The stereoscopic cameras are mounted on a carriage that moves along a circular track, thereby providing for omnidirectional machine vision. g) The control software has been augmented with software that implements innovations reported in two prior NASA Tech Briefs articles: the HIPS algorithm ["Hybrid Image-Plane/Stereo Manipulation" (NPO-30492), Vol. 28, No. 7 (July 2004), page 55] and the CAMPOUT architecture ["An Architecture for Controlling Multiple Robots" (NPO-30345), Vol. 28, No. 10 (October 2004), page 65].

Kennedy, Brett↗

STK Integrated Message Production List Editor (SIMPLE) for CEO Operations

Late in fiscal year 2011, the Crew Earth Observations (CEO) team was tasked to upgrade and replace its mission planning and mission operations software systems, which were developed in the Space Shuttle era of the 1980s and 1990s. The impetuses for this change were the planned transition of all workstations to the Windows 7 64-bit operating system and the desire for more efficient and effective use of Satellite Tool Kit (STK) software required for reliable International Space Station (ISS) Earth location tracking. An additional requirement of this new system was the use of the same SQL database of CEO science sites from the SMMS, which was also being developed. STK Integrated Message Production List Editor (SIMPLE) is the essential, all-in-one tool now used by CEO staff to perform daily ISS mission planning to meet its requirement to acquire astronaut photography of specific sites on Earth. The sites are part of a managed, long-term database that has been defined and developed for scientific, educational, and public interest. SIMPLE's end product is a set of basic time and location data computed for an operator-selected set of targets that the ISS crew will be asked to photograph (photography is typically planned 12 to 36 hours out). The CEO operator uses SIMPLE to (a) specify a payload operations planning period; (b) acquire and validate the best available ephemeris data (vectors) for the ISS during the planning period; (c) ingest and display mission-specific site information from the CEO database; (d) identify and display potential current dynamic event targets as map features; (e) compute and display time and location information for each target; (f) screen and select targets based on known crew availability constraints, obliquity constraints, and real-time evaluated constraints to target visibility due to illumination (sun elevation) and atmospheric conditions (weather); and finally (g) incorporate basic, computed time and location information for each selected target into the daily CEO Target List product (message) for submission to ISS payload planning and integration teams for their review and approval prior to uplink. SIMPLE requires and uses the following resources: an ISS mission planning period Greenwich Mean Time start date/time and end date/time), the best available ISS mission ephemeris data (vectors) for that planning period, the STK software package configured for the ISS, and an ISS mission-specific subset of the CEO sites database. The primary advantages realized by the development and implementation of SIMPLE into the CEO payload operations support activity are a smooth transition to the Windows 7 operating system upon scheduled workstation refresh; streamlining of the input and verification of the current ISS ephemeris (vector data); seamless incorporation of selected contents of the SQL database of science sites; the ability to tag and display potential dynamic event opportunities on orbit track maps; simplification of the display and selection of encountered sites based on crew availability, illumination, obliquity, and weather constraints; the incorporation of high-quality mapping of the Earth with various satellite-based datasets for use in describing targets; and the ability to encapsulate and export the essential selected target elements in XML format for use by onboard Earth-location systems, such as Worldmap. SIMPLE is a carefully designed and crafted in-house software package that includes detailed help files for the user and meticulous internal documentation for future modifications. It was delivered in February 2012 for test and evaluation. Following acceptance, it was implemented for CEO mission operations support in May 2012.

Trenchard, Mike↗

Energy efficient engine: Propulsion system-aircraft integration evaluation

Flight performance and operating economics of future commercial transports utilizing the energy efficient engine were assessed as well as the probability of meeting NASA's goals for TSFC, DOC, noise, and emissions. Results of the initial propulsion systems aircraft integration evaluation presented include estimates of engine performance, predictions of fuel burns, operating costs of the flight propulsion system installed in seven selected advanced study commercial transports, estimates of noise and emissions, considerations of thrust growth, and the achievement-probability analysis.

Owens, R. E.↗

Integrated Refrigeration and Storage for Advanced Liquid Hydrogen Operations

NASA has used liquefied hydrogen (LH2) on a large scale since the beginning of the space program as fuel for the Centaur and Apollo upper stages, and more recently to feed the three space shuttle main engines. The LH2 systems currently in place at the Kennedy Space Center (KSC) launch pads are aging and inefficient compared to the state-of-the-art. Therefore, the need exists to explore advanced technologies and operations that can drive commodity costs down, and provide increased capabilities. The Ground Operations Demonstration Unit for Liquid Hydrogen (GODU-LH2) was developed at KSC to pursue these goals by demonstrating active thermal control of the propellant state by direct removal of heat using a cryocooler. The project has multiple objectives including zero loss storage and transfer, liquefaction of gaseous hydrogen, and densification of liquid hydrogen. The key technology challenge was efficiently integrating the cryogenic refrigerator into the LH2 storage tank. A Linde LR1620 Brayton cycle refrigerator is used to produce up to 900W cooling at 20K, circulating approximately 22 g/s gaseous helium through the hydrogen via approximately 300 m of heat exchanger tubing. The GODU-LH2 system is fully operational, and is currently under test. This paper will discuss the design features of the refrigerator and storage system, as well as the current test results.

Liquefaction↗

MPS Editor - An Integrated Sequencing Environment

In today's operations environment, the teams are smaller and need to be more efficient while still ensuring the safety and success of the mission. In addition, teams often begin working on a mission in its early development phases and continue on the team through actual operations. For these reasons the operations teams want to be presented with a software environment that integrates multiple needed software applications as well as providing them with context sensitive editing support for entering commands and sequences of commands. At Jet Propulsion Laboratory, the Multi-Mission Planning and Sequencing (MPS) Editor provided by the Multi-Mission Ground Systems and Services (MGSS) supports those operational needs.

Streiffert, Barbara A.↗

Initial Analysis of Digitally Enabled Cooperative Operations in Class D Terminal Airspace

The primary contribution of this paper is an initial analysis of integrating digitally enabled cooperative operations (or digital operations for short) with Visual Flight Rules (VFR) and Instrument Flight Rules (IFR) operations in the terminal airspace around a Class D airport, specifically around Fort Worth Alliance airport (KAFW). Enabled by connected digital technologies and automated information exchange, digital operations as envisioned would utilize cooperative practices and operator-responsible separation to ensure safety. In the present study, three conflict management configurations for digital operations were analyzed: 1) centralized with a single instance of a conflict management service to model a scenario with only one fleet operator conducting digital operations or all fleet operators utilizing the same service, 2) federated with two different instances to model a scenario with two different fleet operators conducting digital operations, and 3) fully distributed with a different instance for each digital operation. In simulations in which recorded tracks for VFR and IFR operations were played back and digital operations were modeled that would nominally arrive at KAFW once every 20 minutes (given no conflict resolution maneuvers), there were one or fewer losses of separation (LOS) across the three conflict management configurations. The same result was seen in simulations in which digital operations would nominally arrive at KAFW once every 10 minutes. However, in simulations in which digital operations would nominally arrive at KAFW once every 5 minutes, the number of LOS ranged between six and ten. This highlights the need for follow-on research to investigate the extent to which additional capabilities for digital operations, such as complexity management and/or flow organization, may be needed.

digitally enabled cooperative operations, digital ↗

Initial Analysis of Digitally Enabled Cooperative Operations in Class D Terminal Airspace

The primary contribution of this paper is an initial analysis of integrating digitally enabled cooperative operations (or digital operations for short) with Visual Flight Rules (VFR) and Instrument Flight Rules (IFR) operations in the terminal airspace around a Class D airport, specifically around Fort Worth Alliance airport (KAFW). Enabled by connected digital technologies and automated information exchange, digital operations as envisioned would utilize cooperative practices and operator-responsible separation to ensure safety. In the present study, three conflict management configurations for digital operations were analyzed: 1) centralized with a single instance of a conflict management service to model a scenario with only one fleet operator conducting digital operations or all fleet operators utilizing the same service, 2) federated with two different instances to model a scenario with two different fleet operators conducting digital operations, and 3) fully distributed with a different instance for each digital operation. In simulations in which recorded tracks for VFR and IFR operations were played back and digital operations were modeled that would nominally arrive at KAFW once every 20 minutes (given no conflict resolution maneuvers), there were one or fewer losses of separation (LOS) across the three conflict management configurations. The same result was seen in simulations in which digital operations would nominally arrive at KAFW once every 10 minutes. However, in simulations in which digital operations would nominally arrive at KAFW once every 5 minutes, the number of LOS ranged between six and ten. This highlights the need for follow-on research to investigate the extent to which additional capabilities for digital operations, such as complexity management and/or flow organization, may be needed.

digitally enabled cooperative operations↗

Logic design for dynamic and interactive recovery.

Recovery in a fault-tolerant computer means the continuation of system operation with data integrity after an error occurs. This paper delineates two parallel concepts embodied in the hardware and software functions required for recovery; detection, diagnosis, and reconfiguration for hardware, data integrity, checkpointing, and restart for the software. The hardware relies on the recovery variable set, checking circuits, and diagnostics, and the software relies on the recovery information set, audit, and reconstruct routines, to characterize the system state and assist in recovery when required. Of particular utility is a handware unit, the recovery control unit, which serves as an interface between error detection and software recovery programs in the supervisor and provides dynamic interactive recovery.

Carter, W. C.↗

The Skylab results; Proceedings of the Twentieth Annual Meeting, University of Southern California, Los Angeles, Calif., August 20-22, 1974. Parts 1 & 2

A comprehensive series of papers on the Skylab program, covering integration and testing, operations support, living and working in space, Skylab technology, the role of the Kennedy Space Center in Skylab, the Earth Resources Experiment Package (EREP), the student science program, Apollo Telescope Mount experiments, corollary experiments, and life-sciences data. The topics include: Skylab contamination control; management and control of the missions; extravehicular activity; the repair of major systems elements on Skylab; crew motion disturbances; the design and operation of the Skylab attitude and pointing control system; the performance of solar shields; Comet Kohoutek observations from Skylab; the Skylab food system; and an evaluation of life in Skylab from a medical viewpoint. Individual items are announced in this issue.

Schneider, W. C.↗

A tactile paging system for deaf-blind people, phase 1

A tactile paging system for deaf-blind people has been brought from the concept stage to the development of a first model. The model consists of a central station that transmits coded information via radio link to an on-body (i.e., worn on the wrist) receiving unit, the output from which is a coded vibrotactile signal. The model is a combination of commercially available equipment, customized electronic circuits, and electromechanical transducers. The paging system facilitates communication to deaf-blind clients in an institutional environment as an aid in their training and other activities. Several subunits of the system were individually developed, tested, and integrated into an operating system ready for experimentation and evaluation. The operation and characteristics of the system are described and photographs are shown.

Baer, J. A.↗

The first Spacelab mission

The purpose of Spacelab, an Orbiter-mounted NASA/ESA laboratory, is to include in the Space Transportation System (STS) a payload carrier with maximum flexibility to accommodate multidisciplinary scientific payloads. The major Spacelab configurations obtained by combination of two basic elements, the module and pallet, are described along with the anticipated program of experiments and payloads, and mission management general concept. The first Spacelab 7-day mission is scheduled for flight in the second half of 1980, with the primary objective being to verify system performance capabilities. Detailed attention is given to the payload mission management responsibilities for the first flight, including program control, science management, payload interfaces, integrated payload mission planning, integration requirements, payload specialist training, payload integration, launch site integration, payload flight/mission operations, and postmission activities. The Spacelab configuration (including the long module and one pallet) and the overall schedule for this mission are presented.

Pace, R. E., Jr.↗

Spacelab programme overview

The current activity status of Spacelab, objectives of which are to provide a laboratory and observation facility in space, is surveyed. Program requirements are given, and the basic Spacelab concept is described. The programmatic aspects of the program and some considerations concerning payload integration and payload operations are outlined.

Lord, D. R.↗

Heat capacity mapping radiometer for AEM spacecraft

The operation, maintenance, and integration of the applications explorer mission heat capacity mapping radiometer is illustrated in block diagrams and detail schematics of circuit functions. Data format and logic timing diagrams are included along with radiometric and electronic calibration data. Mechanical and electrical configuration is presented to provide interface details for integration of the HCMR instrument to AEM spacecraft.

Sonnek, G. E.↗