Results for “data transfer nodes” — Page 6

NASA NTRS2002

MDP: Reliable File Transfer for Space Missions

This paper presents work being done at NASA/GSFC (Goddard Space Flight Center) by the Operating Missions as Nodes on the Internet (OMNI) project to demonstrate the application of the Multicast Dissemination Protocol (MDP) to space missions to reliably transfer files. This work builds on previous work by the OMNI project to apply Internet communication technologies to space communication. The goal of this effort is to provide an inexpensive, reliable, standard, and interoperable mechanism for transferring files in the space communication environment. Limited bandwidth, noise, delay, intermittent connectivity, link asymmetry, and one-way links are all possible issues for space missions. Although these are link-layer issues, they can have a profound effect on the performance of transport and application level protocols. MDP, a UDP (User Datagram Protocol)-based reliable file transfer protocol, was designed for multicast environments which have to address these same issues, and it has done so successfully. Developed by the Naval Research Lab in the mid 1990s, MDP is now in daily use by both the US Post Office and the DoD (Department of Defense). This paper describes the use of MDP to provide automated end-to-end data flow for space missions. It examines the results of a parametric study of MDP in a simulated space link environment and discusses the results in terms of their implications for space missions. Lessons learned are addressed, which suggest minor enhancements to the MDP user interface to add specific features for space mission requirements, such as dynamic control of data rate, and a checkpoint/resume capability. These are features that are provided for in the protocol, but are not implemented in the sample MDP application that was provided. A brief look is also taken at the status of standardization. A version of MDP known as NORM (Nack Oriented Reliable Multicast) is in the process of becoming an IETF (Internet Engineering Task Force) standard.

Rash, James↗

NASA NTRS2001

Thermal Analysis for Orbiter and ISS Plume Impingement on International Space Station

The NASA Reaction Control System (RCS) Plume Model (RPM) is an exhaust plume flow field and impingement heating code that has been updated and applied to components of the International Space Station (ISS). The objective of this study was to use this code to determine if plume environments from either Orbiter PRCS jets or ISS reboost and Attitude Control System (ACS) jets cause thermal issues on ISS component surfaces. This impingement analysis becomes increasingly important as the ISS is being assembled with its first permanent crew scheduled to arrive by the end of fall 2000. By early summer 2001 , the ISS will have a number of major components installed such as the Unity (Node 1), Destiny (Lab Module), Zarya (Functional Cargo Block), and Zvezda (Service Module) along with the P6 solar arrays and radiators and the Z-1 truss. Plume heating to these components has been analyzed with the RPM code as well as additional components for missions beyond Flight 6A such as the Propulsion Module (PM), Mobile Servicing System, Space Station Remote Manipulator System, Node 2, and the Cupola. For the past several years NASA/JSC has been developing the methodology to predict plume heating on ISS components. The RPM code is a modified source flow code with capabilities for scarfed nozzles and intersecting plumes that was developed for the 44 Orbiter RCS jets. This code has been validated by comparison with Shuttle Plume Impingement Flight Experiment (SPIFEX) heat flux and pressure data and with CFD and Method of Characteristics solutions. Previous analyses of plume heating predictions to the ISS using RPM have been reported, but did not consider thermal analysis for the components nor jet-firing histories as the Orbiter approaches the ISS docking ports. The RPM code has since been modified to analyze surface temperatures with a lumped mass approach and also uses jet-firing histories to produce pulsed heating rates. In addition, RPM was modified to include plume heating from ISS jets to ISS components where the jet coordinates are specified, together with the engine cant angle. These latter studies have been focused on the PM with plumes from its reboost and ACS jets impinging on various ISS components and also focused on the Japanese H2 Transfer Vehicle (HTV) with the plumes from its reboost engines impinging on the Cupola window. This paper will present plume heating and surface temperature results on a number of ISS components with and without jet-firing histories, evaluate post-flight data, and describe any potential thermal issues

Rochelle, William C.↗

NASA NTRS1994

Characterizing parallel file-access patterns on a large-scale multiprocessor

Rapid increases in the computational speeds of multiprocessors have not been matched by corresponding performance enhancements in the I/O subsystem. To satisfy the large and growing I/O requirements of some parallel scientific applications, we need parallel file systems that can provide high-bandwidth and high-volume data transfer between the I/O subsystem and thousands of processors. Design of such high-performance parallel file systems depends on a thorough grasp of the expected workload. So far there have been no comprehensive usage studies of multiprocessor file systems. Our CHARISMA project intends to fill this void. The first results from our study involve an iPSC/860 at NASA Ames. This paper presents results from a different platform, the CM-5 at the National Center for Supercomputing Applications. The CHARISMA studies are unique because we collect information about every individual read and write request and about the entire mix of applications running on the machines. The results of our trace analysis lead to recommendations for parallel file system design. First the file system should support efficient concurrent access to many files, and I/O requests from many jobs under varying load conditions. Second, it must efficiently manage large files kept open for long periods. Third, it should expect to see small requests predominantly sequential access patterns, application-wide synchronous access, no concurrent file-sharing between jobs appreciable byte and block sharing between processes within jobs, and strong interprocess locality. Finally, the trace data suggest that node-level write caches and collective I/O request interfaces may be useful in certain environments.

Purakayastha, Apratim↗

NASA NTRS2023

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

NASA NTRS2024

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.3.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

NASA NTRS2013

Wireless Integrated Microelectronic Vacuum Sensor System

NASA Stennis Space Center's (SSC's) large rocket engine test facility requires the use of liquid propellants, including the use of cryogenic fluids like liquid hydrogen as fuel, and liquid oxygen as an oxidizer (gases which have been liquefied at very low temperatures). These fluids require special handling, storage, and transfer technology. The biggest problem associated with transferring cryogenic liquids is product loss due to heat transfer. Vacuum jacketed piping is specifically designed to maintain high thermal efficiency so that cryogenic liquids can be transferred with minimal heat transfer. A vacuum jacketed pipe is essentially two pipes in one. There is an inner carrier pipe, in which the cryogenic liquid is actually transferred, and an outer jacket pipe that supports and seals the vacuum insulation, forming the "vacuum jacket." The integrity of the vacuum jacketed transmission lines that transfer the cryogenic fluid from delivery barges to the test stand must be maintained prior to and during engine testing. To monitor the vacuum in these vacuum jacketed transmission lines, vacuum gauge readings are used. At SSC, vacuum gauge measurements are done on a manual rotation basis with two technicians, each using a handheld instrument. Manual collection of vacuum data is labor intensive and uses valuable personnel time. Additionally, there are times when personnel cannot collect the data in a timely fashion (i.e., when a leak is detected, measurements must be taken more often). Additionally, distribution of this data to all interested parties can be cumbersome. To simplify the vacuum-gauge data collection process, automate the data collection, and decrease the labor costs associated with acquiring these measurements, an automated system that monitors the existing gauges was developed by Invocon, Inc. For this project, Invocon developed a Wireless Integrated Microelectronic Vacuum Sensor System (WIMVSS) that provides the ability to gather vacuum-gauge measurements automatically and wirelessly, in near-real time - using a low-maintenance, lowpower sensor mesh network. The WIMVSS operates by using a self-configuring mesh network of wireless sensor units. Mesh networking is a type of networking where each sensor or node can capture and disseminate its own data, but also serve as a relay to receive and transmit data from other sensors. Each sensor node can synchronize with adjacent sensors, and propagate data from one sensor to the next, until the destination is reached. In this case, the destination is a Network Interface Unit (NIU). The WIMVSS sensors are mounted on the existing vacuum gauges. Information gathered by the sensors is sent to the NIU. Because of the mesh networking, if a sensor cannot directly send the data to the NIU, it can be propagated through the network of sensors. The NIU requires antenna access to the sensor units, AC power, and an Ethernet connection. The NIU bridges the sensor network to a WIMVSS server via an Ethernet connection. The server is configured with a database, a Web server, and proprietary interface software that makes it possible for the vacuum measurements from vacuum jacketed fluid lines to be saved, retrieved, and then displayed from any Web-enabled PC that has access to the Internet. Authorized users can then simply access the data from any PC with Internet connection. Commands can also be sent directly from the Web interface for control and maintenance of the sensor network. The technology enabled by the WIMVSS decreases labor required for gathering vacuum measurements, increases access to vacuum data by making it available on any computer with access to the Internet, increases the frequency with which data points can be acquired for evaluating the system, and decreases the recurring cost of the sensors by using off-the-shelf components and integrating these with heritage vacuum gauges.

Krug, Eric↗

NASA NTRSDate not supplied

Lunar Node – 1: Initial Flight Results and the Role of Surface Psuedolites in Lunar Navigation

On February 22, 2024, the Intuitive Machines IM-1 NOVA-C lander, nick-named Odysseus, landed on the lunar surface, carrying with it a cadre of NASA scientific and technology demonstration payloads. These payloads and missions marked the first delivery of NASA instruments to operate from the lunar surface since the Apollo landings. One of these payloads is Lunar Node -1 (LN-1), a navigation beacon demonstration mission. The payload was designed and built by NASA’s Marshall Space Flight Center. The payload’s main goal was to demonstrate and provide insight into the use of lunar surface-based radio navigation aids. As part of the mission, LN-1 successfully conducted multiple one-way transmissions from the NOVA-C vehicle to Deep Space Network ground receivers using its onboard S-band transmitter, while being disciplined by an onboard Space Chip Scale Atomic Clock. LN-1 transmitted to DSN on an almost daily basis during transit to the moon, including two surface passes. The payload was originally plan to conduct 7-10 days of surface operation as an always-on beacon. These passes focused on evaluating two main navigation approaches: performance and stability of ranging using time-based transfer techniques on a cubesat size and grade platform, as well as one-way psuedonoise ranging approaches. To assess performance, the measurements were compared to independent navigation solutions using multiple approaches including: one-way Doppler tracking, two-way Doppler Tracking, and visual verification of the landing location provided by visual observations from orbital platforms. While the mission only conducted limited surface operations, the data provides some initial insight to performance form the lunar surface. These results are compared with initial ground-based testing as well as continued evaluation of the flight-space platform using multiple grades of oscillators for maintaining clock and frequency stability. These focus on the timing stability of platform in a deep-space environment as well variations in state determination. Given these insights, this paper provides additional description and evaluation of how this approach can be utilized as part of a broader lunar navigation architecture, such as being developed and deployed across multiple international space agencies. Analysis is provided to develop overall timing requirements and assessment of operational scenarios, such as orbit and surface location determination. In addition, the results support discussion as to how surface pseudolites could best be used within existing standard signal definitions, such as defined in the LunaNet Interoperability Specifications. This will consider concerns such as the near-/far- problem as well as operational considerations, including whether a beacon is better suited as two- or one-way ranging platform. The use cases are focused on how these psuedolites can provide additional coverage to augment and support planned operational coverage. For example, this analysis provides analysis of mid-latitude surface missions, where there may be limited geometry and availability of orbital relays. The results will show how these navigation psuedolites can fit within the developing architecture to provide additional robustness, capability, and support multiple use cases. Lastly, the paper will discuss challenges and next steps to be addressed in the implementation and testing of a follow-on payload and a continued path towards demonstration and integration of this capability into Lunar PNT architectures.

Evan Anzalone↗

NASA NTRSDate not supplied

Lunar Node – 1: Initial Flight Results and the Role of Surface Psuedolites in Lunar Navigation

On February 22, 2024, Intuitive Machines NOVA-C lander, nick-named Odysseus, landed on the lunar surface, carrying with it a cadre of NASA scientific and technology demonstration payloads. These payloads and missions marked the first delivery of NASA instruments to operate from the lunar surface since the Apollo landings. One of these payloads is Lunar Node -1 (LN-1), a navigation beacon demonstration mission. The payload was designed and built by NASA’s Marshall Space Flight Center. The payload’s main goal was to demonstrate and provide insight into the use of lunar surface-based radio navigation aids. As part of the mission, LN-1 successfully conducted multiple one-way transmissions from the NOVA-C vehicle to Deep Space Network ground receivers using its onboard S-band transmitter, while being disciplined by an onboard Space Chip Scale Atomic Clock. LN-1 transmitted to DSN on an almost daily basis during transit to the moon, including two surface passes. The payload was originally plan to conduct 7-10 days of surface operation as an always-on beacon. These passes focused on evaluating two main navigation approaches: performance and stability of ranging using time-based transfer techniques on a cubesat size and grade platform, as well as one-way psuedonoise ranging approaches. To assess performance, the measurements were compared to independent navigation solutions using multiple approaches including: one-way Doppler tracking, two-way Doppler Tracking, and visual verification of the landing location provided by visual observations from orbital platforms. While the mission only conducted limited surface operations, the data provides some initial insight to performance form the lunar surface. These results are compared with initial ground-based testing as well as continued evaluation of the flight-space platform using multiple grades of oscillators for maintaining clock and frequency stability. These focus on the timing stability of platform in a deep-space environment as well variations in state determination. Given these insights, this paper provides additional description and evaluation of how this approach can be utilized as part of a broader lunar navigation architecture, such as being developed and deployed across multiple international space agencies. Analysis is provided to develop overall timing requirements and assessment of operational scenarios, such as orbit and surface location determination. In addition, the results support discussion as to how surface pseudolites could best be used within existing standard signal definitions, such as defined in the LunaNet Interoperability Specifications. This will consider concerns such as the near-/far- problem as well as operational considerations, including whether a beacon is better suited as two- or one-way ranging platform. The use cases are focused on how these psuedolites can provide additional coverage to augment and support planned operational coverage. For example, this analysis provides analysis of mid-latitude surface missions, where there may be limited geometry and availability of orbital relays. The results will show how these navigation psuedolites can fit within the developing architecture to provide additional robustness, capability, and support multiple use cases. Lastly, the paper will discuss challenges and next steps to be addressed in the implementation and testing of a follow-on payload and a continued path towards demonstration and integration of this capability into Lunar PNT architectures.

Evan J Anzalone↗

NASA NTRS2000

Internet Access to Spacecraft

The Operating Missions as Nodes on the Internet (OMNI) project at NASA's Goddard Space flight Center (GSFC), is demonstrating the use of standard Internet protocols for spacecraft communication systems. This year, demonstrations of Internet access to a flying spacecraft have been performed with the UoSAT-12 spacecraft owned and operated by Surrey Satellite Technology Ltd. (SSTL). Previously, demonstrations were performed using a ground satellite simulator and NASA's Tracking and Data Relay Satellite System (TDRSS). These activities are part of NASA's Space Operations Management Office (SOMO) Technology Program, The work is focused on defining the communication architecture for future NASA missions to support both NASA's "faster, better, cheaper" concept and to enable new types of collaborative science. The use of standard Internet communication technology for spacecraft simplifies design, supports initial integration and test across an IP based network, and enables direct communication between scientists and instruments as well as between different spacecraft, The most recent demonstrations consisted of uploading an Internet Protocol (IP) software stack to the UoSAT- 12 spacecraft, simple modifications to the SSTL ground station, and a series of tests to measure performance of various Internet applications. The spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 3 months. The tests included basic network connectivity (PING), automated clock synchronization (NTP), and reliable file transfers (FTP). Future tests are planned to include additional protocols such as Mobile IP, e-mail, and virtual private networks (VPN) to enable automated, operational spacecraft communication networks. The work performed and results of the initial phase of tests are summarized in this paper. This work is funded and directed by NASA/GSFC with technical leadership by CSC in arrangement with SSTL, and Vytek Wireless.

Rash, James↗

NASA NTRS2009

The Radio Frequency Health Node Wireless Sensor System

The Radio Frequency Health Node (RFHN) wireless sensor system differs from other wireless sensor systems in ways originally intended to enhance utility as an instrumentation system for a spacecraft. The RFHN can also be adapted to use in terrestrial applications in which there are requirements for operational flexibility and integrability into higher-level instrumentation and data acquisition systems. As shown in the figure, the heart of the system is the RFHN, which is a unit that passes commands and data between (1) one or more commercially available wireless sensor units (optionally, also including wired sensor units) and (2) command and data interfaces with a local control computer that may be part of the spacecraft or other engineering system in which the wireless sensor system is installed. In turn, the local control computer can be in radio or wire communication with a remote control computer that may be part of a higher-level system. The remote control computer, acting via the local control computer and the RFHN, cannot only monitor readout data from the sensor units but can also remotely configure (program or reprogram) the RFHN and the sensor units during operation. In a spacecraft application, the RFHN and the sensor units can also be configured more nearly directly, prior to launch, via a serial interface that includes an umbilical cable between the spacecraft and ground support equipment. In either case, the RFHN wireless sensor system has the flexibility to be configured, as required, with different numbers and types of sensors for different applications. The RFHN can be used to effect realtime transfer of data from, and commands to, the wireless sensor units. It can also store data for later retrieval by an external computer. The RFHN communicates with the wireless sensor units via a radio transceiver module. The modular design of the RFHN makes it possible to add radio transceiver modules as needed to accommodate additional sets of wireless sensor units. The RFHN includes a core module that performs generic computer functions, including management of power and input, output, processing, and storage of data. In a typical application, the processing capabilities in the RFHN are utilized to perform preprocessing, trending, and fusion of sensor data. The core module also serves as the unit through which the remote control computer configures the sensor units and the rest of the RFHN.

Valencia, J. Emilio↗

NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗

NASA NTRSDate not supplied

Modeling and Simulation of Tank Pressure Control using Zero-Boil Off Active Thermal Control for LOXSAT Technology Demonstration Mission

To-date, research and modeling of cryogenic fluid management technologies (CFM) for spaceflight has been limited to ground tests, short-duration zero-g simulations (e.g. drop towers), and small-scale experiments on-orbit. There has not been a large-scale flight demonstration of a flight-like system. As future NASA missions to take humans further from Earth will require large, in-space cryogenic propulsion vehicles, it is imperative to begin collecting flight data for these systems to accurately model and design future vehicles. To meet this goal, NASA awarded tipping point technology demonstration awards to Eta Space, Lockheed Martin, Space Exploration Technologies (SpaceX), and United Launch Alliance (ULA) to demonstrate on-orbit storage and transfer of cryogenic propellant. For its award, Eta Space is developing LOXSAT-1. It is a small satellite that will be launched on a Rocket Lab Electron rocket. The spacecraft consists of a Rocket Lab Photon spacecraft bus with a primary payload of a spherical liquid oxygen (LOX) storage tank with thermodynamic control systems. The primary objective of the mission is to demonstrate zero-boil-off storage of liquid oxygen. To accomplish this objective, the payload is equipped with an active thermal control system fluid loop that consists of propellant management device (PMD), positive-displacement pump, heat exchanger connected to a cryocooler, and a spray bar mixing injector. When the fluid loop is operating, fluid is drawn from the tank by the PMD and pumped through the heat exchanger, lowering the fluid temperature below the fluid temperature in the tank. This subcooled liquid is then injected back into the tank through the spray bar. The subcooled injected liquid has two effects. If it is sprayed into the ullage space, the injected liquid will form into jets or droplets and exchange heat with the ullage gas. This will cool and condense the gas, reducing the pressure in the tank. Additionally, the liquid that is not sprayed through the ullage, as well as any remaining liquid spray from the ullage, will rejoin the liquid mass of the tank, lowering the bulk temperature of the liquid. These combines effects provide for zero-boil off pressure control by lowering the tank pressure and the liquid saturation pressure simultaneously, ensuring the liquid stays subcooled. To model these complex mechanics and predict the performance of the active thermal control system, NASA is providing Eta Space with 3 parallel models of the tank. The approach of providing 3 different models allows for cross-checking and comparisons between the three to better understand how different modeling assumptions and selection semi-empirical factors affects the modeling result. Additionally, developing 3 models provides three different schemes for numerical simulation, providing confidence that results depict real physical phenomenon and not numerical quirks of the program. Within the tank thermodynamics, there are two primary areas of heat transfer we concern ourselves with: the heat transfer between the ullage space and the droplet spray, and between the ullage space and bulk liquid. For the droplet heat transfer, there are multiple sets of assumptions that can be made and correlations that can be used. Currently, two working models - the TankSIM model and Easy5 model – provide for an overview of the different approaches available. The TankSIM model and Easy5 model use two different models for droplet heating and evaporation that illustrate how the models use different types of mechanisms to arrive at the same answer. For the TankSIM model, droplets are treated as spheres of constant radius. Heat is transferred from the ullage to the droplet and warms the droplet until it reaches saturation, then the droplet begins evaporating and reducing its radius and mass. To calculate the heat transfer coefficient between the droplet and ullage, the Ranz-Marshall correlation is used. To determine the number of droplets in the ullage, a resident mass approach is used. This approach averages the number of droplets such that residuals at the start-up and shut-off of the spray bar cancel out. This same approach is used in the Easy5 model. The GFSSP model implements a linked list to track individual droplet “nodes” within the model. For the Easy5 model, the droplet is assumed to have an interface at a temperature equal to the saturation temperature corresponding to the pressure of the gas phase. The heat transfer from the gas to the interface and the interface to the droplet bulk is then calculated, and the net mass transfer between the droplet and interface is determined by performing an energy balance across the interface. For the gas side of the interface, the Ranz-Marshall correlation is used. For the liquid side of the interface, a variety of correlations were tried, including Kronig and Brink (1950) and effective conductivity models. As a result of these assumptions, the Easy5 model currently predicts faster depressurization, as at saturated vapor conditions, the heat transfer coeffect on the liquid side for the Easy5 model is greater than the heat transfer coefficient predicted by Ranz-Marshall used in the TankSIM code. This greater heat flux translates into faster condensation of the saturated ullage gas. At the bulk liquid to ullage interface, the models are in much closer agreement. Both models model the ullage as a sphere centered within the bulk liquid in the tank, and both use the energy-jumping boundary condition to model heat and mass transfer across the interface. There are slight differences in how the interface temperature is calculated, however. The Easy5 model assumes the temperature of the interface is equal to the saturation temperature associated with the pressure of the gas phase. The TankSIM model calculates this temperature with Alabovskii’s equation, which provides a correction factor for interface temperatures. Analysis tasks are focused on determining rates of depressurization within the tank during active cooling operation. To maintain net positive suction head at the pump inlet, the tank pressure cannot fall faster than the saturation pressure associated with the temperature of the bulk liquid. Additionally, there is interest in analyzing the performance of the loop at different pump speeds and cryocooler input powers. Adjusting the flowrate affects both the performance of the heat exchanger between the cryocooler and pumped liquid, and the heat transfer between the droplet spray and the ullage. Ideally, a pump speed and cryocooler power can be selected that will allow the tank to operate in zero-boil-off mode with a very narrow range of storage pressure.

Cameron J. Hines↗

NASA NTRSDate not supplied

Modeling and Simulation of Tank Pressure Control using Zero-Boil Off Active Thermal Control for LOXSAT Technology Demonstration Mission

To-date, research and modeling of cryogenic fluid management technologies (CFM) for spaceflight has been limited to ground tests, short-duration zero-g simulations (e.g. drop towers), and small-scale experiments on-orbit. There has not been a large-scale flight demonstration of a flight-like system. As future NASA missions to take humans further from Earth will require large, in-space cryogenic propulsion vehicles, it is imperative to begin collecting flight data for these systems to accurately model and design future vehicles. To meet this goal, NASA awarded tipping point technology demonstration awards to Eta Space, Lockheed Martin, Space Exploration Technologies (SpaceX), and United Launch Alliance (ULA) to demonstrate on-orbit storage and transfer of cryogenic propellant. For its award, Eta Space is developing LOXSAT-1. It is a small satellite that will be launched on a Rocket Lab Electron rocket. The spacecraft consists of a Rocket Lab Photon spacecraft bus with a primary payload of a spherical liquid oxygen (LOX) storage tank with thermodynamic control systems. The primary objective of the mission is to demonstrate zero-boil-off storage of liquid oxygen. To accomplish this objective, the payload is equipped with an active thermal control system fluid loop that consists of propellant management device (PMD), positive-displacement pump, heat exchanger connected to a cryocooler, and a spray bar mixing injector. When the fluid loop is operating, fluid is drawn from the tank by the PMD and pumped through the heat exchanger, lowering the fluid temperature below the fluid temperature in the tank. This subcooled liquid is then injected back into the tank through the spray bar. The subcooled injected liquid has two effects. If it is sprayed into the ullage space, the injected liquid will form into jets or droplets and exchange heat with the ullage gas. This will cool and condense the gas, reducing the pressure in the tank. Additionally, the liquid that is not sprayed through the ullage, as well as any remaining liquid spray from the ullage, will rejoin the liquid mass of the tank, lowering the bulk temperature of the liquid. These combines effects provide for zero-boil off pressure control by lowering the tank pressure and the liquid saturation pressure simultaneously, ensuring the liquid stays subcooled. To model these complex mechanics and predict the performance of the active thermal control system, NASA is providing Eta Space with 3 parallel models of the tank. The approach of providing 3 different models allows for cross-checking and comparisons between the three to better understand how different modeling assumptions and selection semi-empirical factors affects the modeling result. Additionally, developing 3 models provides three different schemes for numerical simulation, providing confidence that results depict real physical phenomenon and not numerical quirks of the program. Within the tank thermodynamics, there are two primary areas of heat transfer we concern ourselves with: the heat transfer between the ullage space and the droplet spray, and between the ullage space and bulk liquid. For the droplet heat transfer, there are multiple sets of assumptions that can be made and correlations that can be used. Currently, two working models - the TankSIM model and Easy5 model – provide for an overview of the different approaches available. The TankSIM model and Easy5 model use two different models for droplet heating and evaporation that illustrate how the models use different types of mechanisms to arrive at the same answer. For the TankSIM model, droplets are treated as spheres of constant radius. Heat is transferred from the ullage to the droplet and warms the droplet until it reaches saturation, then the droplet begins evaporating and reducing its radius and mass. To calculate the heat transfer coefficient between the droplet and ullage, the Ranz-Marshall correlation is used. To determine the number of droplets in the ullage, a resident mass approach is used. This approach averages the number of droplets such that residuals at the start-up and shut-off of the spray bar cancel out. This same approach is used in the Easy5 model. The GFSSP model implements a linked list to track individual droplet “nodes” within the model. For the Easy5 model, the droplet is assumed to have an interface at a temperature equal to the saturation temperature corresponding to the pressure of the gas phase. The heat transfer from the gas to the interface and the interface to the droplet bulk is then calculated, and the net mass transfer between the droplet and interface is determined by performing an energy balance across the interface. For the gas side of the interface, the Ranz-Marshall correlation is used. For the liquid side of the interface, a variety of correlations were tried, including Kronig and Brink (1950) and effective conductivity models. As a result of these assumptions, the Easy5 model currently predicts faster depressurization, as at saturated vapor conditions, the heat transfer coeffect on the liquid side for the Easy5 model is greater than the heat transfer coefficient predicted by Ranz-Marshall used in the TankSIM code. This greater heat flux translates into faster condensation of the saturated ullage gas. At the bulk liquid to ullage interface, the models are in much closer agreement. Both models model the ullage as a sphere centered within the bulk liquid in the tank, and both use the energy-jumping boundary condition to model heat and mass transfer across the interface. There are slight differences in how the interface temperature is calculated, however. The Easy5 model assumes the temperature of the interface is equal to the saturation temperature associated with the pressure of the gas phase. The TankSIM model calculates this temperature with Alabovskii’s equation, which provides a correction factor for interface temperatures. Analysis tasks are focused on determining rates of depressurization within the tank during active cooling operation. To maintain net positive suction head at the pump inlet, the tank pressure cannot fall faster than the saturation pressure associated with the temperature of the bulk liquid. Additionally, there is interest in analyzing the performance of the loop at different pump speeds and cryocooler input powers. Adjusting the flowrate affects both the performance of the heat exchanger between the cryocooler and pumped liquid, and the heat transfer between the droplet spray and the ullage. Ideally, a pump speed and cryocooler power can be selected that will allow the tank to operate in zero-boil-off mode with a very narrow range of storage pressure.

zero boil-off↗

NASA NTRSDate not supplied

Modeling and Simulation of Tank Pressure Control using Zero-Boil Off Active Thermal Control for LOXSAT Technology Demonstration Mission

To-date, research and modeling of cryogenic fluid management technologies (CFM) for spaceflight has been limited to ground tests, short-duration zero-g simulations (e.g. drop towers), and small-scale experiments on-orbit. There has not been a large-scale flight demonstration of a flight-like system. As future NASA missions to take humans further from Earth will require large, in-space cryogenic propulsion vehicles, it is imperative to begin collecting flight data for these systems to accurately model and design future vehicles. To meet this goal, NASA awarded tipping point technology demonstration awards to Eta Space, Lockheed Martin, Space Exploration Technologies (SpaceX), and United Launch Alliance (ULA) to demonstrate on-orbit storage and transfer of cryogenic propellant. For its award, Eta Space is developing LOXSAT-1. It is a small satellite that will be launched on a Rocket Lab Electron rocket. The spacecraft consists of a Rocket Lab Photon spacecraft bus with a primary payload of a spherical liquid oxygen (LOX) storage tank with thermodynamic control systems. The primary objective of the mission is to demonstrate zero-boil-off storage of liquid oxygen. To accomplish this objective, the payload is equipped with an active thermal control system fluid loop that consists of propellant management device (PMD), positive-displacement pump, heat exchanger connected to a cryocooler, and a spray bar mixing injector. When the fluid loop is operating, fluid is drawn from the tank by the PMD and pumped through the heat exchanger, lowering the fluid temperature below the fluid temperature in the tank. This subcooled liquid is then injected back into the tank through the spray bar. The subcooled injected liquid has two effects. If it is sprayed into the ullage space, the injected liquid will form into jets or droplets and exchange heat with the ullage gas. This will cool and condense the gas, reducing the pressure in the tank. Additionally, the liquid that is not sprayed through the ullage, as well as any remaining liquid spray from the ullage, will rejoin the liquid mass of the tank, lowering the bulk temperature of the liquid. These combines effects provide for zero-boil off pressure control by lowering the tank pressure and the liquid saturation pressure simultaneously, ensuring the liquid stays subcooled. To model these complex mechanics and predict the performance of the active thermal control system, NASA is providing Eta Space with 3 parallel models of the tank. The approach of providing 3 different models allows for cross-checking and comparisons between the three to better understand how different modeling assumptions and selection semi-empirical factors affects the modeling result. Additionally, developing 3 models provides three different schemes for numerical simulation, providing confidence that results depict real physical phenomenon and not numerical quirks of the program. Within the tank thermodynamics, there are two primary areas of heat transfer we concern ourselves with: the heat transfer between the ullage space and the droplet spray, and between the ullage space and bulk liquid. For the droplet heat transfer, there are multiple sets of assumptions that can be made and correlations that can be used. Currently, two working models - the TankSIM model and Easy5 model – provide for an overview of the different approaches available. The TankSIM model and Easy5 model use two different models for droplet heating and evaporation that illustrate how the models use different types of mechanisms to arrive at the same answer. For the TankSIM model, droplets are treated as spheres of constant radius. Heat is transferred from the ullage to the droplet and warms the droplet until it reaches saturation, then the droplet begins evaporating and reducing its radius and mass. To calculate the heat transfer coefficient between the droplet and ullage, the Ranz-Marshall correlation is used. To determine the number of droplets in the ullage, a resident mass approach is used. This approach averages the number of droplets such that residuals at the start-up and shut-off of the spray bar cancel out. This same approach is used in the Easy5 model. The GFSSP model implements a linked list to track individual droplet “nodes” within the model. For the Easy5 model, the droplet is assumed to have an interface at a temperature equal to the saturation temperature corresponding to the pressure of the gas phase. The heat transfer from the gas to the interface and the interface to the droplet bulk is then calculated, and the net mass transfer between the droplet and interface is determined by performing an energy balance across the interface. For the gas side of the interface, the Ranz-Marshall correlation is used. For the liquid side of the interface, a variety of correlations were tried, including Kronig and Brink (1950) and effective conductivity models. As a result of these assumptions, the Easy5 model currently predicts faster depressurization, as at saturated vapor conditions, the heat transfer coeffect on the liquid side for the Easy5 model is greater than the heat transfer coefficient predicted by Ranz-Marshall used in the TankSIM code. This greater heat flux translates into faster condensation of the saturated ullage gas. At the bulk liquid to ullage interface, the models are in much closer agreement. Both models model the ullage as a sphere centered within the bulk liquid in the tank, and both use the energy-jumping boundary condition to model heat and mass transfer across the interface. There are slight differences in how the interface temperature is calculated, however. The Easy5 model assumes the temperature of the interface is equal to the saturation temperature associated with the pressure of the gas phase. The TankSIM model calculates this temperature with Alabovskii’s equation, which provides a correction factor for interface temperatures. Analysis tasks are focused on determining rates of depressurization within the tank during active cooling operation. To maintain net positive suction head at the pump inlet, the tank pressure cannot fall faster than the saturation pressure associated with the temperature of the bulk liquid. Additionally, there is interest in analyzing the performance of the loop at different pump speeds and cryocooler input powers. Adjusting the flowrate affects both the performance of the heat exchanger between the cryocooler and pumped liquid, and the heat transfer between the droplet spray and the ullage. Ideally, a pump speed and cryocooler power can be selected that will allow the tank to operate in zero-boil-off mode with a very narrow range of storage pressure.

zero boil-off↗

NASA NTRSDate not supplied

Modeling and Simulation of Tank Pressure Control using Zero-Boiloff Active Thermal Control for LOXSAT Technology Demonstration Mission

To-date, research and modeling of cryogenic fluid management technologies (CFM) for spaceflight has been limited to ground tests, short-duration zero-g simulations (e.g. drop towers), and small-scale experiments on-orbit. There has not been a large-scale flight demonstration of a flight-like system. As future NASA missions to take humans further from Earth will require large, in-space cryogenic propulsion vehicles, it is imperative to begin collecting flight data for these systems to accurately model and design future vehicles. To meet this goal, NASA awarded tipping point technology demonstration awards to Eta Space, Lockheed Martin, Space Exploration Technologies (SpaceX), and United Launch Alliance (ULA) to demonstrate on-orbit storage and transfer of cryogenic propellant. For its award, Eta Space is developing LOXSAT-1. It is a small satellite that will be launched on a Rocket Lab Electron rocket. The spacecraft consists of a Rocket Lab Photon spacecraft bus with a primary payload of a spherical liquid oxygen (LOX) storage tank with thermodynamic control systems. The primary objective of the mission is to demonstrate zero-boil-off storage of liquid oxygen. To accomplish this objective, the payload is equipped with an active thermal control system fluid loop that consists of propellant management device (PMD), positive-displacement pump, heat exchanger connected to a cryocooler, and a spray bar mixing injector. When the fluid loop is operating, fluid is drawn from the tank by the PMD and pumped through the heat exchanger, lowering the fluid temperature below the fluid temperature in the tank. This subcooled liquid is then injected back into the tank through the spray bar. The subcooled injected liquid has two effects. If it is sprayed into the ullage space, the injected liquid will form into jets or droplets and exchange heat with the ullage gas. This will cool and condense the gas, reducing the pressure in the tank. Additionally, the liquid that is not sprayed through the ullage, as well as any remaining liquid spray from the ullage, will rejoin the liquid mass of the tank, lowering the bulk temperature of the liquid. These combines effects provide for zero-boil off pressure control by lowering the tank pressure and the liquid saturation pressure simultaneously, ensuring the liquid stays subcooled. To model these complex mechanics and predict the performance of the active thermal control system, NASA is providing Eta Space with 3 parallel models of the tank. The approach of providing 3 different models allows for cross-checking and comparisons between the three to better understand how different modeling assumptions and selection semi-empirical factors affects the modeling result. Additionally, developing 3 models provides three different schemes for numerical simulation, providing confidence that results depict real physical phenomenon and not numerical quirks of the program. Within the tank thermodynamics, there are two primary areas of heat transfer we concern ourselves with: the heat transfer between the ullage space and the droplet spray, and between the ullage space and bulk liquid. For the droplet heat transfer, there are multiple sets of assumptions that can be made and correlations that can be used. Currently, two working models - the TankSIM model and Easy5 model – provide for an overview of the different approaches available. The TankSIM model and Easy5 model use two different models for droplet heating and evaporation that illustrate how the models use different types of mechanisms to arrive at the same answer. For the TankSIM model, droplets are treated as spheres of constant radius. Heat is transferred from the ullage to the droplet and warms the droplet until it reaches saturation, then the droplet begins evaporating and reducing its radius and mass. To calculate the heat transfer coefficient between the droplet and ullage, the Ranz-Marshall correlation is used. To determine the number of droplets in the ullage, a resident mass approach is used. This approach averages the number of droplets such that residuals at the start-up and shut-off of the spray bar cancel out. This same approach is used in the Easy5 model. The GFSSP model implements a linked list to track individual droplet “nodes” within the model. For the Easy5 model, the droplet is assumed to have an interface at a temperature equal to the saturation temperature corresponding to the pressure of the gas phase. The heat transfer from the gas to the interface and the interface to the droplet bulk is then calculated, and the net mass transfer between the droplet and interface is determined by performing an energy balance across the interface. For the gas side of the interface, the Ranz-Marshall correlation is used. For the liquid side of the interface, a variety of correlations were tried, including Kronig and Brink (1950) and effective conductivity models. As a result of these assumptions, the Easy5 model currently predicts faster depressurization, as at saturated vapor conditions, the heat transfer coeffect on the liquid side for the Easy5 model is greater than the heat transfer coefficient predicted by Ranz-Marshall used in the TankSIM code. This greater heat flux translates into faster condensation of the saturated ullage gas. At the bulk liquid to ullage interface, the models are in much closer agreement. Both models model the ullage as a sphere centered within the bulk liquid in the tank, and both use the energy-jumping boundary condition to model heat and mass transfer across the interface. There are slight differences in how the interface temperature is calculated, however. The Easy5 model assumes the temperature of the interface is equal to the saturation temperature associated with the pressure of the gas phase. The TankSIM model calculates this temperature with Alabovskii’s equation, which provides a correction factor for interface temperatures. Analysis tasks are focused on determining rates of depressurization within the tank during active cooling operation. To maintain net positive suction head at the pump inlet, the tank pressure cannot fall faster than the saturation pressure associated with the temperature of the bulk liquid. Additionally, there is interest in analyzing the performance of the loop at different pump speeds and cryocooler input powers. Adjusting the flowrate affects both the performance of the heat exchanger between the cryocooler and pumped liquid, and the heat transfer between the droplet spray and the ullage. Ideally, a pump speed and cryocooler power can be selected that will allow the tank to operate in zero-boil-off mode with a very narrow range of storage pressure.

zero boil-off↗