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 design, construction, and testing of a complete system to produce karyotypes and chromosome measurement data from human blood samples, and a basis for statistical analysis of quantitative chromosome measurement data is described. The prototype was assembled, tested, and evaluated on clinical material and thoroughly documented.
The National Aeronautics and Space Administration (NASA) Advanced Air Mobility (AAM) National Campaign (NC) is researching the means by which future Urban Air Mobility (UAM) aircraft will operate safely in an integrated and scalable airspace architecture. Consistent with this objective, the NASA NC Airspace Procedures team designed a matrix to evaluate UAM instrument flight procedure design, flyability and interoperability of candidate departure, enroute, and approach architectures in live flight or simulation. The Procedure Automation Rating Matrix (PARM) is a multi-dimensional rating scale designed to provide direct feedback from test pilots and operators to airspace procedure designers developing airspace constructs for the integration and scalability of AAM operations in the National Airspace System (NAS). The PARM is assessed using a hierarchical decision tree that guides the operator through a ten-point alpha-numeric rating scale initiated either with or without the use of automation.
The NASA Johnson Space Center has developed a nanosatellite-class Free Flyer intended for future external inspection and remote viewing of human spacecraft. The Miniature Autonomous Extravehicular Robotic Camera (Mini AERCam) technology demonstration unit has been integrated into the approximate form and function of a flight system. The spherical Mini AERCam Free Flyer is 7.5 inches in diameter and weighs approximately 10 pounds, yet it incorporates significant additional capabilities compared to the 35-pound, 14-inch diameter AERCam Sprint that flew as a Shuttle flight experiment in 1997. Mini AERCam hosts a full suite of miniaturized avionics, instrumentation, communications, navigation, power, propulsion, and imaging subsystems, including digital video cameras and a high resolution still image camera. The vehicle is designed for either remotely piloted operations or supervised autonomous operations, including automatic stationkeeping, point-to-point maneuvering, and waypoint tracking. The Mini AERCam Free Flyer is accompanied by a sophisticated control station for command and control, as well as a docking system for automated deployment, docking, and recharge at a parent spacecraft. Free Flyer functional testing has been conducted successfully on both an airbearing table and in a six-degree-of-freedom closed-loop orbital simulation with avionics hardware in the loop. Mini AERCam aims to provide beneficial on-orbit views that cannot be obtained from fixed cameras, cameras on robotic manipulators, or cameras carried by crewmembers during extravehicular activities (EVA s). On Shuttle or International Space Station (ISS), for example, Mini AERCam could support external robotic operations by supplying orthogonal views to the intravehicular activity (IVA) robotic operator, supply views of EVA operations to IVA and/or ground crews monitoring the EVA, and carry out independent visual inspections of areas of interest around the spacecraft. To enable these future benefits with minimal impact on IVA operators and ground controllers, the Mini AERCam system architecture incorporates intelligent systems attributes that support various autonomous capabilities. 1) A robust command sequencer enables task-level command scripting. Command scripting is employed for operations such as automatic inspection scans over a region of interest, and operator-hands-off automated docking. 2) A system manager built on the same expert-system software as the command sequencer provides detection and smart-response capability for potential system-level anomalies, like loss of communications between the Free Flyer and control station. 3) An AERCam dynamics manager provides nominal and off-nominal management of guidance, navigation, and control (GN&C) functions. It is employed for safe trajectory monitoring, contingency maneuvering, and related roles. This paper will describe these architectural components of Mini AERCam autonomy, as well as the interaction of these elements with a human operator during supervised autonomous control.
The pace of progress in the design of integrated circuits continues to amaze observers inside and outside of the industry. Three decades ago, a 50 transistor chip was a technological wonder. Fifteen year later, a 5000 transistor device would 'wow' the crowds. Today, 50,000 transistor chips will earn a 'not too bad' assessment, but it takes 500,000 to really leave an impression. In 1975 a typical ASIC device had 1000 transistors, took one year to first samples (and two years to production) and sold for about 5 cents per transistor. Today's 50,000 transistor gate array takes about 4 months from spec to silicon, works the first time, and sells for about 0.02 cents per transistor. Fifteen years ago, the single most laborious and error prone step in IC design was the physical layout. Today, most IC's never see the hand of a layout designer: and automatic place and route tool converts the engineer's computer captured schematic to a complete physical design using a gate array or a library of standard cells also created by software rather than by designers. CAD has also been a generous benefactor to the digital design process. The architect of today's digital systems creates the design using an RTL or other high level simulator. Then the designer pushes a button to invoke the logic synthesizer-optimizer tool. A fault analyzer checks the result for testability and suggests where scan based cells will improve test coverage. One obstinate holdout amidst this parade of progress is the automation of analog design and its reduction to semi-custom techniques. This paper investigates the application of CAD techniques to analog design.
Interval Management (IM) is a concept designed to be used by air traffic controllers and flight crews to more efficiently and precisely manage inter-aircraft spacing. Both government and industry have been working together to develop the IM concept and standards for both ground automation and supporting avionics. NASA contracted with Boeing, Honeywell, and United Airlines to build and flight test an avionics prototype based on NASA's spacing algorithm and conduct a flight test. The flight test investigated four different types of IM operations over the course of nineteen days, and included en route, arrival, and final approach phases of flight. This paper examines the spacing accuracy achieved during the flight test and the rate of speed commands provided to the flight crew. Many of the time-based IM operations met or exceeded the operational design goals set out in the standards for the maintain operations and a subset of the achieve operations. Those operations which did not meet the goals were due to issues that are identified and will be further analyzed.
The proposed work entails the design, assembly, testing, and delivery of a turn-key system for the semi-automated determination of protein solubilities as a function of temperature. The system will utilize optical scintillation as a means of detecting and monitoring nucleation and crystallite growth during temperature lowering (or raising, with retrograde solubility systems). The deliverables of this contract are: (1) turn-key scintillation system for the semi-automatic determination of protein solubilities as a function of temperature, (2) instructions and software package for the operation of the scintillation system, and (3) one semi-annual and one final report including the test results obtained for ovostatin with the above scintillation system.
Radio frequency interference on space-to-ground communications links can degrade performance and disrupt the transfer of critical data. These interference events become increasingly likely as more users enter the spectrum, due in part to shared spectrum allocations and scheduling conflicts. If this interference could be detected and mitigated by an automated system, then link performance and reliability in these scenarios could be improved. This report describes the implementation and evaluation of an automated interference mitigation system that provides this functionality. The system uses Cyclic Autocorrelation (CAC) signal processing techniques to monitor the spectrum and detect interfering signals, and it applies a multi-objective optimization approach to mitigate interference by changing link parameters to continuously optimize the link. The implementation was evaluated to characterize its signal detection capabilities for various link qualities and to compare its link management performance to Adaptive Coding and Modulation (ACM) and Constant Coding and Modulation (CCM) when in the presence of randomized interference. In the latter evaluation, the interference mitigation system achieved the highest average throughput in each tested scenario. With these results, the proposed solution provides the groundwork for further automated link management capabilities and continued investigation into interference mitigation approaches.
The capability to transfer mass between spacecraft is necessary for many mission scenarios. Docking and berthing operations have enabled fluid, electrical, crew and equipment transfers to some degree on all manned space operations since the Gemini program. The Apollo program performed some sophisticated docking maneuvers to land men on the moon and return them safely to Earth. These programs primarily transferred crew, equipment, and pressurized atmosphere between docked spacecraft. The International Space Station (ISS) U.S. modules are connected by Common Berthing Mechanism (CBM) portals. They provide many feed-through ports for electrical, and fluid transfer between modules, as well as a large diameter crew and equipment tunnel. Fluid and electrical jumpers are manually installed after the CBM sealing surfaces have been securely mated to maintain the pressurized cabin environment. CBM berthing and subsequent fluid transfer capability requires a lengthy manual process involving an active interface that mates with a passive half. The Androgynous Peripheral Attach System (MAS) a Russian technology that docked the Russian Zarya module to Unity, or Node 1, is a more complex system that also is capable of fuel transfer, enabling refueling of the Russian re-boost engines on ISS. For several years, a Low Impact Docking System (LIDS) has been under development at Johnson Space Center (JSC). This docking technology has a requirement to be androgynous in order to allow the fabrication of a single configuration that can dock with all other LIDS units. It is desired to make electrical and fluid coupling mating an automated process to enable routine docking and undocking operations to support future exploration missions. It is envisioned that modular design and vehicle assembly will require an efficient LIDS for fuel, electrical, crew, and equipment transfer. Marshall Space Flight Center (MSFC) has joined the LIDS development effort and plans to employ fluid transfer concepts and technology from previous development programs, such as the Automated Fluid Interface System (AFIS) and the Ohital Fluid Transfer System (OFTS) that were developed and tested by MSFC. Orbital Expressderived robotic satellite servicing technology is scheduled to fly soon to demonstrate fluid transfer technology developed for the Air Force. This paper will compare known technology against possible fluid transfer requirements for LIDS to develop design strategies for automated fluid transfer.
Two dimensional spectral types for each of the stars observed in the global astrometric interferometer for astrophysics (GAIA) mission would provide additional information for the galactic structure and stellar evolution studies, as well as helping in the identification of unusual objects and populations. The classification of the large quantity generated spectra requires that automated techniques are implemented. Approaches for the automatic classification are reviewed, and a metric-distance method is discussed. In tests, the metric-distance method produced spectral types with mean errors comparable to those of human classifiers working at similar resolution. Data and equipment requirements for an automated classification survey, are discussed. A program of auxiliary observations is proposed to yield spectral types and radial velocities for the GAIA-observed stars.
Progress was made in the three following areas. In the rule-based modeling area, two papers related to identification and significane testing of rule-based models were presented. In the area of operator aiding, research focused on aiding operators in novel failure situations; a discrete control modeling approach to aiding PLANT operators was developed; and a set of guidelines were developed for implementing automation. In the area of flight simulator hardware and software, the hardware will be completed within two months and initial simulation software will then be integrated and tested.
The experiment described seeks to improve the understanding of the fundamental mechanisms that constitute nucleate pool boiling. The vehicle for accomplishing this is an investigation, including tests to be conducted in microgravity and coupled with appropriate analyses, of the heat transfer and vapor bubble dynamics associated with nucleation, bubble growth/collapse and subsequent motion, considering the interrelations between buoyancy, momentum and surface tension which will govern the motion of the vapor and surrounding liquid, as a function of the heating rate at the heat transfer surface and the temperature level and distribution in the bulk liquid. The experiment is designed to be contained within the confines of a Get-Away-Special Canister (GAS Can) installed in the bay of the space shuttle. When the shuttle reaches orbit, the experiment will be turned on and testing will proceed automatically. In the proposed Pool Boiling Experiment a pool of liquid, initially at a precisely defined pressure and temperature, will be subjected to a step imposed heat flux from a semitransparent thin-film heater forming part of one wall of the container such that boiling is initiated and maintained for a defined period of time at a constant pressure level. Transient measurements of the heater surface and fluid temperatures near the surface will be made, noting especially the conditions at the onset of boiling, along with motion photography of the boiling process in two simultaneous views, from beneath the heating surface and from the side. The conduct of the experiment and the data acquisition will be completely automated and self-contained. For the initial flight, a total of nine tests are proposed, with three levels of heat flux and three levels of subcooling. The design process used in the development and check-out of the compact photographic/optics system for the Pool Boiling Experiment is documented.
The general objectives of the NASA/UCF Automated Knowledge Generation Project were the development of an intelligent software system that could access CAD design data bases, interpret them, and generate a diagnostic knowledge base in the form of a system model. The initial area of concentration is in the diagnosis of the process control system using the Knowledge-based Autonomous Test Engineer (KATE) diagnostic system. A secondary objective was the study of general problems of automated knowledge generation. A prototype was developed, based on object-oriented language (Flavors).
With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.
With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.
With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.
An electron beam test facility, which consists of a precision multidimensional manipulator built into an ultra-high-vacuum bell jar, was designed, fabricated, and operated at Lewis Research Center. The position within the bell jar of a Faraday cup which samples current in the electron beam under test, is controlled by the manipulator. Three orthogonal axes of motion are controlled by stepping motors driven by digital indexers, and the positions are displayed on electronic totalizers. In the transverse directions, the limits of travel are approximately + or - 2.5 cm from the center with a precision of 2.54 micron (0.0001 in.); in the axial direction, approximately 15.0 cm of travel are permitted with an accuracy of 12.7 micron (0.0005 in.). In addition, two manually operated motions are provided, the pitch and yaw of the Faraday cup with respect to the electron beam can be adjusted to within a few degrees. The current is sensed by pulse transformers and the data are processed by a dual channel box car averager with a digital output. The beam tester can be operated manually or it can be programmed for automated operation. In the automated mode, the beam tester is controlled by a microcomputer (installed at the test site) which communicates with a minicomputer at the central computing facility. The data are recorded and later processed by computer to obtain the desired graphical presentations.
The Technology Capability Level-3 (TCL3) flight tests were conducted at six different test sites located across the USA from March to May of 2018. The campaign resulted in over 830 data collection flights using 28 different aircraft and involving 20 flight crews. Flights not only varied in duration, but also in the environments and terrains over which they flew. The TCL3 tests highlighted four different types of tests: three tests focused on Communication, Navigation and Surveillance (CNS); six tests focused on Sense and Avoid (SAA) technologies; six tests focused on USS Data and Information Exchange (DAT); and five tests focused on exploring fundamental Concepts of the project (CON). This document presents data collected during the TCL3 tests that informed the operator’s experiences—the quality of the unmanned aerial system (UAS) Service Supplier (USS) information that the operator was provided with, the usefulness of this information, and the usability of the automation, both while airborne and on the ground. It is intended to complement the reports written by the test sites and the quantitative reports and presentations of the UAS Traffic Management (UTM) project. With the goal of instructing what the minimum information requirements and/or best practices might be in TCL3 operations, the driving enquiry was: How do you get the information you need, when you need it, to successfully fly a UAS in UTM airspace? This enquiry touches on two requirements for displays, which are to provide adequate situation awareness (SA) and to share information through a USS. The six test sites participating in the TCL3 tests flew a subset of the 20 tests (outlined above), with most sites working on a subset of each of the four types: Communications, Navigation and Surveillance (CNS); DAT; CON; and Sense and Avoid (SAA). The, mainly qualitative, data addressed in this report was collected by the AOL (Airspace Operations Laboratory) both on-site and remotely for each test. The data consists of the contents of end-of-day debriefs, end-of-day surveys, observer notes, and flight test information, all submitted as part of the Data Management Plan (DMP).
The Feces Monitoring System (FMS) Program designed, fabricated, assembled and tested an engineering model waste collector system (WCS) to be used in support of life science and medical experiments related to Shuttle missions. The FMS design was patterned closely after the Shuttle WCS, including: interface provisions; mounting; configuration; and operating procedures. These similarities make it possible to eventually substitute an FMS for the Shuttle WCS of Orbiter. In addition, several advanced waste collection features, including the capability of real-time inertial fecal separation and fecal mass measurement and sampling were incorporated into the FMS design.