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 experience acquired through development, implementation and operation of the KeplerK2 science pipelines can provide lessons learned for the development of science pipelines for other missions such as NASA's Transiting Exoplanet Survey Satellite, and ESA's PLATO mission.
The experience acquired through development, implementation and operation of the Kepler K2 science pipelines can provide lessons learned for the development of science pipelines for other missions such as NASA's Transiting Exoplanet Survey Satellite and ESA's PLATO mission.
In response to the growing need for empirical data on pulse detonation engine performance and operation, NASA Marshall Space Flight Center has developed and placed into operation a low-cost gas-fed pulse detonation research engine. The guiding design strategy was to achieve a simple and flexible research apparatus, which was inexpensive to build and operate. As such, the engine was designed to operate as a heat sink device, and testing was limited to burst-mode operation with run durations of a few seconds. Wherever possible, maximum use was made of standard off-the-shelf industrial or automotive components. The 5-cm diameter primary tube is about 90-cm long and has been outfitted with a multitude of sensor and optical ports. The primary tube is fed by a coaxial injector through an initiator tube, which is inserted directly into the injector head face. Four auxiliary coaxial injectors are also integrated into the injector head assembly. All propellant flow is controlled with industrial solenoid valves. An automotive electronic ignition system was adapted for use, and spark plugs are mounted in both tubes so that a variety of ignition schemes can be examined. A microprocessor-based fiber-optic engine control system was developed to provide precise control over valve and ignition timing. Initial shakedown testing with hydrogen/oxygen mixtures verified the need for Schelkin spirals in both the initiator and primary tubes to ensure rapid development of the detonation wave. Measured pressure wave time-of-flight indicated detonation velocities of 2.4 km/sec and 2.2 km/sec in the initiator and primary tubes, respectively. These values implied a fuel-lean mixture corresponding to an H2 volume fraction near 0.5. The axial distribution for the detonation velocity was found to be essentially constant along the primary tube. Time-resolved thrust profiles were also acquired for both underfilled and overfilled tube conditions. These profiles are consistent with previous time-resolved measurements on single-cycle tubes where the thrust is found to peak as the detonation wave exits the tube, and decay as the tube blows down.
Artemis Internal Science Training Team partners closely with the xEVA Trainers and Crew Training Office in FOD; together, all parties acknowledge the importance of integrated science and operations skill-building within training for surface operations.
This paper presents a summary of studies performed by the Space Division of Rockwell under contract to the Langley Research Center of the NASA. The studies specifically addressed requirements and concepts for erectable structures ranging in size from 100 to 300 meters using the Shuttle Orbiter as the operation/assembly base. This paper discusses various types of structural configurations and building block elements and the criteria which influence their designs. A brief review is given concerning the subject of flight control. An assembly concept is presented - showing how the Orbiter may be equipped and operated to build large area structures. Estimates are also given for cargo bay stowage and mission timelines.
Vehicle assembly building, where propulsion and spacecraft stages are brought together, as key structure in Apollo-Saturn V prelaunch checkout operations
The Space Shuttle Integrated Main Propulsion System (IMPS) consists of the External Tank (ET), Orbiter Main Propulsion System (MPS), and Space Shuttle Main Engines (SSMEs). The IMPS is tasked with the storage, conditioning, distribution, and combustion of cryogenic liquid hydrogen (LH2) and liquid oxygen (LO2) propellants to provide first and second stage thrust for achieving orbital velocity. The design, certification, and operation of the associated IMPS hardware have produced many lessons learned over the course of the Space Shuttle Program (SSP). A subset of these items will be discussed in this paper for consideration when designing, building, and operating future spacecraft propulsion systems. This paper will focus on lessons learned related to Orbiter MPS and is the first of a planned series to address the subject matter.
The Six Degree-of-Freedom Dynamic Test System (SDTS) is a test facility at the National Aeronautics and Space Administration (NASA) Johnson Space Center in Houston, Texas for performing dynamic verification of space structures and hardware. Some examples of past and current tests include the verification of on-orbit robotic inspection systems, space vehicle assembly procedures and docking/berthing systems. The facility is able to integrate a dynamic simulation of on-orbit spacecraft mating or demating using flight-like mechanical interface hardware. A force moment sensor is utilized for input to the simulation during the contact phase, thus simulating the contact dynamics. While the verification of flight hardware presents many unique challenges, one particular area of interest is with respect to the use of external measurement systems to ensure accurate feedback of dynamic contact. There are many commercial off-the-shelf (COTS) measurement systems available on the market, and the test facility measurement systems have evolved over time to include two separate COTS systems. The first system incorporates infra-red sensing cameras, while the second system employs a laser interferometer to determine position and orientation data. The specific technical challenges with the measurement systems in a large dynamic environment include changing thermal and humidity levels, operational area and measurement volume, dynamic tracking, and data synchronization. The facility is located in an expansive high-bay area that is occasionally exposed to outside temperature when large retractable doors at each end of the building are opened. The laser interferometer system, in particular, is vulnerable to the environmental changes in the building. The operational area of the test facility itself is sizeable, ranging from seven meters wide and five meters deep to as much as seven meters high. Both facility measurement systems have desirable measurement volumes and the accuracies vary within the respective volumes. In addition, because this is a dynamic facility with a moving test bed, direct line-of-sight may not be available at all times between the measurement sensors and the tracking targets. Finally, the feedback data from the active test bed along with the two external measurement systems must be synchronized to allow for data correlation. To ensure the desired accuracy and resolution of these systems, calibration of the systems must be performed regularly. New innovations in sensor technology itself are periodically incorporated into the facility s overall measurement scheme. In addressing the challenges of the measurement systems, the facility is able to provide essential position and orientation data to verify the dynamic performance of space flight hardware.
The purpose here is to provide a top-level look at the stewardship functions performed in space operations, and to identify the major issues and challenges that must be addressed to build intelligent systems that can realistically support operations functions. The focus is on decision support activities involving monitoring, state assessment, goal generation, plan generation, and plan execution. The bottom line is that problem solving in the space operations domain is a very complex process. A variety of knowledge constructs, representations, and reasoning processes are necessary to support effective human problem solving. Emulating these kinds of capabilities in intelligent systems offers major technical challenges that the artificial intelligence community is only beginning to address.
The Space Operations Center (SOC) orbital space station program operations are described. A work breakdown structure for the general purpose support equipment, construction and transportation support, and resupply and logistics support systems is given. The basis for the design of each element is presented, and a mass estimate for each element supplied. The SOC build-up operation, construction, flight support, and satellite servicing operations are described. Detailed programmatics and cost analysis are presented.
The NASA Operational Simulator for Small Satellites (NOS3) is a suite of open-source software tools to aid in areas such as software development, integration & test (I&T), mission operations/training, verification and validation (V&V), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, operational interface/ground software, dynamics and environment simulations, and software-based hardware models. NOS3 has just recently been open-sourced by NASA and is available for immediate use. It enables the development of flight software (FSW) early in the project life cycle when hardware availability is limited. Small satellite development suffers from extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETUs). To alleviate the need to provide a hardware test-bed for each developer/tester, NOS3 hardware models are based upon characteristic data or manufacturer's data sheets for each individual component. The NOS3 hardware models' fidelity is such that FSW executes unaware that physical hardware is not present. This allows FSW binaries to be compiled for both the simulation environment and the flight computer without changing the FSW source code. For hardware models that provide data which is dependent upon the environment and spacecraft dynamics, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulator) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for V&V of larger missions such as James Webb Space Telescope (JWST). As hardware is selected and becomes available, drivers can be added to the NOS3 environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. NOS3 was actively used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat and the Lunar IceCube CubeSat. As NOS3 matures, hardware models have been added for common small satellite components such as GPS receivers, electrical power systems and batteries, and antenna systems.
For decades, NASA has employed different operational approaches for human and robotic missions. Human spaceflight missions to the Moon and in low Earth orbit have relied upon near-continuous communication with minimal time delays. During these missions, astronauts and mission control communicate interactively to perform tasks and resolve problems in real-time. In contrast, deep-space robotic missions are designed for operations in the presence of significant communication delay - from tens of minutes to hours. Consequently, robotic missions typically employ meticulously scripted and validated command sequences that are intermittently uplinked to the robot for independent execution over long periods. Over the next few years, however, we will see increasing use of robots that blend these two operational approaches. These interactive exploration robots will be remotely operated by humans on Earth or from a spacecraft. These robots will be used to support astronauts on the International Space Station (ISS), to conduct new missions to the Moon, and potentially to enable remote exploration of planetary surfaces in real-time. In this talk, I will discuss the technical challenges associated with building and operating robots in this manner, along with lessons learned from research conducted with the ISS and in the field.
NASA's Chandra X-Ray Observatory, designed for three years of operation with a goal of five years is now entering its 15-th year of operation. Thanks to its superb angular resolution, the Observatory continues to yield new and exciting results, many of which were totally unanticipated prior to launch. We discuss the current technical status, review recent scientific highlights, indicate a few future directions, and present what we feel is the most important lesson learned from our experience of building and operating this great observatory.
About 40% of the budget of a scientific spacecraft mission is usually consumed by Mission Operations & Data Analysis (MO&DA) with MO driving these costs. In the current practice, MO is separated from spacecraft design and comes in focus relatively late in the mission life cycle. As a result, spacecraft may be designed that are very difficult to operate. NASA centers have extensive MO expertise but often lessons learned in one mission are not exploited for other parallel or future missions. A significant reduction of MO costs is essential to ensure a continuing and growing access to space for the scientific community. We are addressing some of these issues with a highly automated payload operations and command system for an existing mission, the Extreme Ultraviolet Explorer (EUVE). EUVE is currently operated jointly by the Goddard Space Flight Center (GSFC), responsible for spacecraft operations, and the Center for Extreme Ultraviolet Astrophysics (CEA) of the University of California, Berkeley, which controls the telescopes and scientific instruments aboard the satellite. The new automated system is being developed by a team including personnel from the NASA Ames Research Center (ARC), the Jet Propulsion Laboratory (JPL) and the Center for EUV Astrophysics (CEA). An important goal of the project is to provide AI-based technology that can be easily operated by nonspecialists in AI. Another important goal is the reusability of the techniques for other missions. Models of the EUVE spacecraft need to be built both for planning/scheduling and for monitoring. In both cases, our modeling tools allow the assembly of a spacecraft model from separate sub-models of the various spacecraft subsystems. These sub-models are reusable; therefore, building mission operations systems for another small satellite mission will require choosing pre-existing modules, reparametrizing them with respect to the actual satellite telemetry information, and reassembling them in a new model. We briefly describe the EUVE mission and indicate why it is particularly suitable for the task. Then we briefly outline our current work in mission planning/scheduling and spacecraft and instrument health monitoring.
The inductive monitoring system (IMS) is a system of computer hardware and software for automated monitoring of the performance, operational condition, physical integrity, and other aspects of the health of a complex engineering system (e.g., an industrial process line or a spacecraft). The input to the IMS consists of streams of digitized readings from sensors in the monitored system. The IMS determines the type and amount of any deviation of the monitored system from a nominal or normal ( healthy ) condition on the basis of a comparison between (1) vectors constructed from the incoming sensor data and (2) corresponding vectors in a database of nominal or normal behavior. The term inductive reflects the use of a process reminiscent of traditional mathematical induction to learn about normal operation and build the nominal-condition database. The IMS offers two major advantages over prior computational monitoring systems: The computational burden of the IMS is significantly smaller, and there is no need for abnormal-condition sensor data for training the IMS to recognize abnormal conditions. The figure schematically depicts the relationships among the computational processes effected by the IMS. Training sensor data are gathered during normal operation of the monitored system, detailed computational simulation of operation of the monitored system, or both. The training data are formed into vectors that are used to generate the database. The vectors in the database are clustered into regions that represent normal or nominal operation. Once the database has been generated, the IMS compares the vectors of incoming sensor data with vectors representative of the clusters. The monitored system is deemed to be operating normally or abnormally, depending on whether the vector of incoming sensor data is or is not, respectively, sufficiently close to one of the clusters. For this purpose, a distance between two vectors is calculated by a suitable metric (e.g., Euclidean distance) and "sufficiently close" signifies lying at a distance less than a specified threshold value. It must be emphasized that although the IMS is intended to detect off-nominal or abnormal performance or health, it is not necessarily capable of performing a thorough or detailed diagnosis. Limited diagnostic information may be available under some circumstances. For example, the distance of a vector of incoming sensor data from the nearest cluster could serve as an indication of the severity of a malfunction. The identity of the nearest cluster may be a clue as to the identity of the malfunctioning component or subsystem. It is possible to decrease the IMS computation time by use of a combination of cluster-indexing and -retrieval methods. For example, in one method, the distances between each cluster and two or more reference vectors can be used for the purpose of indexing and retrieval. The clusters are sorted into a list according to these distance values, typically in ascending order of distance. When a set of input data arrives and is to be tested, the data are first arranged as an ordered set (that is, a vector). The distances from the input vector to the reference points are computed. The search of clusters from the list can then be limited to those clusters lying within a certain distance range from the input vector; the computation time is reduced by not searching the clusters at a greater distance.
… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.
… or, “It’s in the details, how to make complicated software perform like complicated hardware.” In attempts to minimize development time and quickly build an operational vehicle, NASA’s Space Launch System (SLS) has had to be intentional about integrated testing. Constraints on budget and schedule have required balance between testing needs and the desire for an integrated flight vehicle as soon as possible. To provide key insights early in design and analysis cycles, a large amount of effort has shifted into maturing and validating models at the component level with integrated testing as a means to validate their integration. In terms of SLS Navigation, this, and the model-based design approach have pushed explicit requirements for sensor models to be validated against flight hardware to high precision. This paper covers the approach taken to verify and validate the models for the two key navigation sensors on the SLS vehicle, the Redundant Inertial Navigation Sensor and the Rate Gyro Assembly. These models are used in performance evaluation, fault detection, and operations development extensively. Using a mix of data from hardware vendor documentation and testing reports, limited in-house testing, and integration activities, these models were able to be validated against flight hardware at multiple levels, from the internal software design to statistical behavior at the raw sensor and integrated box levels. The high level of insight into the hardware elements is instrumental to support flight certification activities and building confidence in SLS Navigation capability. Focused testing enabled additional insight and validation that proved invaluable and the resulting insights were used to focus and mature models. Additionally, of having validated performance-based hardware models enables a wide breadth of activities including detailed fault detection studies and integration into future vehicle frameworks, such as an upper stage and provide a valuable asset to continued SLS analysis and design.
This paper presents selected features of a human factors oriented plan for a Space Station Freedom (SSF) ground Discipline Operations Center (DOC) that is integrated with other work areas used by multidisciplinary life scientists. This combined facility is referred to as an integrated DOC or IDOC. This plan is based upon the assumption that there will be a constantly changing array of specialized equipment and procedures used by life sciences principal investigators (PI) on the ground which must be linked to SSF through various DOC systems. Other sites will also be able to communicate with SSF (Anon., 1992). It is also assumed that cost reduction will be a major design consideration and that one integrated structure will be less expensive to build and operate than two separate ones. Since both the DOC personnel and PIs will need to communicate with the flight crew aboard SSF, the general interconnect architecture of the PIs' communication linkage is considered here. Key human factor design elements of this plan include: a candidate facility layout which accommodates three (3), multipurpose, rapidly reconfigurable work areas (suites) and consequent user traffic flow considerations, a multimedia telecommunications support capability, functional (human) traffic flow, optimized internal illumination and acoustics requirements, selected volumetric and safety requirements, and other architectural design parameters.