Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “command process”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,225 records · Page 68

DER Cybersecurity Detection and Response Suite

SAND2024-08475O The Distributed Energy Resource (DER) Cybersecurity Detection and Response Suite is a solution for distributed energy resource (DER) systems. The DER Security Orchestration, Automation, and Response (SOAR) solution that uses alerts from signature- and behavior-based Intrusion Detection Systems are intended to be deployed as bump-in-the-wire (BITW) devices in front of DER equipment. The fielded application would use multiple intrusion detection systems that report data to SOAR to respond to cyberattacks. The suite consists of two software components: • The proactive intrusion detection and mitigation system (PIDMS) secures grid-edge photovoltaic smart inverters and other equipment in distributed energy resource systems. It is a distributed BITW solution; cyber and physical data are automatically processed using network inspection tools and custom machine learning algorithms to detect abnormal events and correlate cyber-physical events. • The Security Orchestration, Automation, and Response for Distributed Energy Resources (SOAR4DER) application ingests data from several intrusion detection systems to quickly block attacks and revert DER systems to good states. Using a collection of intrusion detection system technologies on a BITW device, it incorporates physical and cyber data to detect abnormal and potential malicious behaviors. Multiple SOAR playbooks then use the intrusion detection system data streams to automatically defend the system. SOAR4DER system testing showed detection and response times under 30 seconds for all adversary reconnaissance, denial-of-service attacks, malicious Modbus commands, brute-force logins, and machine-in-the-middle attacks. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Johnson, Jay↗

Non-Invasive Assessment of Susceptibility to Ventricular Arrhythmias During Simulated Microgravity

The Cardiovascular Alterations Team is currently conducting studies to determine what alterations in hemodynamic regulation result from sixteen days of simulated microgravity exposure in normal human subjects. In this project we make additional measurements on these same study subjects in order to determine whether there is an increase in susceptibility to ventricular arrhythmias resulting from simulated microgravity exposure. Numerous anecdotal and documented reports from the past 30 years suggest that the incidence of ventricular arrhythmias among astronauts is increased during space flight. For example, documented runs of ventricular tachycardia have been recorded from crew members of Skylab and Mir, there was much attention given by the lay press to Mir Commander Vasily Tslbliyev's complaints of heart rhythm irregularities in July of 1997, and cardiovascular mechanisms may have been causal in the recent death of an experimental primate shortly after return from space. In 1986, a Mir cosmonaut, Alexander Laveikin, was brought home and replaced with an alternate cosmonaut as a result of cardiac dysrhythmias that began during extravehicular activity. Furthermore, at a joint NASA/NSBRI workshop held in January 1998, cardiac arrhythmias were identified as the highest priority cardiovascular risk to a human Mars mission. Despite the evidence for the risk of a potentially lethal arrhythmia resulting from microgravity exposure, the effects of space flight and the associated physiologic stresses on cardiac conduction processes are not known, and an increase in cardiac susceptibility to arrhythmias has never been quantified. In this project, we are determining whether simulated space flight increases the risk of developing life-threatening heart rhythm disturbances such as sustained ventricular tachycardia (defined as ventricular tachycardia lasting at least 30 seconds or resulting in hemodynamic collapse) and ventricular fibrillation. We are obtaining measures of cardiac susceptibility to ventricular arrhythmias in subjects exposed to simulated space flight in the Human Studies Core protocol being conducted by the Cardiovascular Alterations Team, which involves sixteen days .of bed rest. In particular, we are applying a powerful new non-invasive technology, developed in Professor Cohen's laboratory at MIT for the quantitative assessment of the risk of life-threatening ventricular arrhythmias. This technology involves the measurement of microvolt levels of T wave alternans (TWA) during exercise stress, and was recently granted approval by the Food and Drug Administration to be used for the clinical evaluation of patients suspected to be at risk of ventricular arrhythmias. In addition, we are obtaining 24 hour Holter monitoring (to detect non-sustained ventricular tachycardia and to assess heart rate variability). We are also conducting protocols to obtain these same measures on a monthly basis for up to four months in subjects in the Bone Demineralization/calcium Metaboloism Team's long term bed rest study.

Cohen, Richard J.↗

Aladyn - Adaptive Neural Network Molecular Dynamics Simulation Code: Computational Materials Mini-Application

This report provides an overview and commands description of the Computational Materials mini-application, Aladyn. Aladyn is a simple molecular dynamics code written in FORTRAN 2008, which is designed to demonstrate the use of adaptive neural networks (ANNs) in atomistic simulations. The role of ANNs is to reproduce the very complex energy landscape resulting from the atomic interactions in materials with the accuracy of quantum mechanics-based energy calculations. The ANN is trained on a large set of atomic structures calculated using the density functional theory (DFT) method. The Aladyn code is being released to serve as a training testbed for students and professors in academia to explore possible optimization algorithms for parallel computing on multicore central processing unit (CPU) computers or computers utilizing many core architectures based on graphic processing units (GPUs). The effort is related to the High Performance Computing Incubator (HPCI) project at NASA Langley Research Center.

Yamakov, Vesselin I.↗

Electron-proton spectrometer: Summary for critical design review

The electron-proton spectrometer (EPS) is mounted external to the Skylab module complex on the command service module. It is designed to make a 2 pi omni-directional measurement of electrons and protons which result from solar flares or enhancement of the radiation belts. The EPS data will provide accurate radiation dose information so that uncertain Relative biological effectiveness factors are eliminated by measuring the external particle spectra. Astronaut radiation safety, therefore, can be ensured, as the EPS data can be used to correct or qualify radiation dose measurements recorded by other radiation measuring instrumentation within the Skylab module complex. The EPS has the capability of measuring and extremely wide dynamic radiation dose rate range, approaching 10 to the 7th power. Simultaneously the EPS has the capability to process data from extremely high radiation fields such as might be encountered in the wake of an intense solar flare.

Source record↗

Seeker 1.0: Prototype Robotic Free Flying Inspector Mission Overview

Seeker 1.0 is a prototype free flying robot that will one day be capable of inspecting human-rated spacecraft. Building off previous free flyer experience, this technology will eventually improve safety of human spacecraft by offering a variety of inspection capabilities for both routine and emergency scenarios providing increased capability and safety over current inspection methods. Seeker 1.0 is capable of 6 degree of freedom flight via a cold gas propulsion system and can operate up to 1 hour via a semi-autonomous guidance, navigation, and control system. The prototype spacecraft is capable of capturing still images at a variety of resolutions up to 13 MP. The initial test flight utilizes a command and data relay box called Kenobi. Kenobi is a derivative of the Seeker design and will communicate between Cygnus and Seeker and store data for post-mission downlink. Seeker and Kenobi have launched inside a NanoRacks External CubeSat Deployer (NRCSD-E) attached to the NG-11 Cygnus ISS resupply vehicle and will operate after Cygnus departs ISS and moves to a safe altitude. Operations will last approximately 30 minutes and will consist of basic vehicle maneuvers while capturing high-resolution still images. With any remaining time and propellant, Seeker will demonstrate additional safety capabilities and maneuvers required for operations around a crewed spacecraft. The Seeker project utilized the Class IE process that allows for streamlined flight hardware development and increased mission risk tolerance.

Spacecraft Inspection↗

Utilities for master source code distribution: MAX and Friends

MAX is a program for the manipulation of FORTRAN master source code (MSC). This is a technique by which one maintains one and only one master copy of a FORTRAN program under a program developing system, which for MAX is assumed to be VAX/VMS. The master copy is not intended to be directly compiled. Instead it must be pre-processed by MAX to produce compilable instances. These instances may correspond to different code versions (for example, double precision versus single precision), different machines (for example, IBM, CDC, Cray) or different operating systems (i.e., VAX/VMS versus VAX/UNIX). The advantage os using a master source is more pronounced in complex application programs that are developed and maintained over many years and are to be transported and executed on several computer environments. The version lag problem that plagues many such programs is avoided by this approach. MAX is complemented by several auxiliary programs that perform nonessential functions. The ensemble is collectively known as MAX and Friends. All of these programs, including MAX, are executed as foreign VAX/VMS commands and can easily be hidden in customized VMS command procedures.

Felippa, Carlos A.↗

Functional description of a command and control language tutor

The status of an ongoing project to explore the application of Intelligent Tutoring System (ITS) technology to NASA command and control languages is described. The primary objective of the current phase of the project is to develop a user interface for an ITS to assist NASA control center personnel in learning Systems Test and Operations Language (STOL). Although this ITS will be developed for Gamma Ray Observatory operators, it will be designed with sufficient flexibility so that its modules may serve as an ITS for other control languages such as the User Interface Language (UIL). The focus of this phase is to develop at least one other form of STOL representation to complement the operational STOL interface. Such an alternative representation would be adaptively employed during the tutoring session to facilitate the learning process. This is a key feature of this ITS which distinguishes it from a simulator that is only capable of representing the operational environment.

Elke, David R.↗

Designing an autonomous environment for mission critical operation of the EUVE satellite

Since the launch of NASA's Extreme Ultraviolet Explorer (EUVE) satellite in 1992, there has only been a handful of occurrences that have warranted manual intervention in the EUVE Science Operations Center (ESOC). So, in an effort to reduce costs, the current environment is being redesigned to utilize a combination of off-the-shelf packages and recently developed artificial intelligence (AI) software to automate the monitoring of the science payload and ground systems. The successful implementation of systemic automation would allow the ESOC to evolve from a seven day/week, three shift operation, to a seven day/week one shift operation. First, it was necessary to identify all areas considered mission critical. These were defined as follows: (1) The telemetry stream must be monitored autonomously and anomalies identified. (2) Duty personnel must be automatically paged and informed of the occurrence of an anomaly. (3) The 'basic' state of the ground system must be assessed. (4) Monitors should check that the systems and processes needed to continue in a 'healthy' operational mode are working at all times. (5) Network loads should be monitored to ensure that they stay within established limits. (6) Connectivity to Goddard Space Flight Center (GSFC) systems should be monitored as well, not just for connectivity of the network itself but also for the ability to transfer files. (7) All necessary peripheral devices should be monitored. This would include the disks, routers, tape drives, printers, tape carousel, and power supplies. (8) System daemons such as the archival daemon, the Sybase server, the payload monitoring software, and any other necessary processes should be monitored to ensure that they are operational. (9) The monitoring system needs to be redundant so that the failure of a single machine will not paralyze the monitors. (10) Notification should be done by means of looking though a table of the pager numbers for current 'on call' personnel. The software should be capable of dialing out to notify, sending email, and producing error logs. (11) The system should have knowledge of when real-time passes and tape recorder dumps will occur and should know that these passes and data transmissions are successful. Once the design criteria were established, the design team split into two groups: one that addressed the tracking, commanding, and health and safety of the science payload and another group that addressed the ground systems and communications aspects of the overall system.

Abedini, Annadiana↗

Distributing Data to Hand-Held Devices in a Wireless Network

ADROIT is a developmental computer program for real-time distribution of complex data streams for display on Web-enabled, portable terminals held by members of an operational team of a spacecraft-command-and-control center who may be located away from the center. Examples of such terminals include personal data assistants, laptop computers, and cellular telephones. ADROIT would make it unnecessary to equip each terminal with platform- specific software for access to the data streams or with software that implements the information-sharing protocol used to deliver telemetry data to clients in the center. ADROIT is a combination of middleware plus software specific to the center. (Middleware enables one application program to communicate with another by performing such functions as conversion, translation, consolidation, and/or integration.) ADROIT translates a data stream (voice, video, or alphanumerical data) from the center into Extensible Markup Language, effectuates a subscription process to determine who gets what data when, and presents the data to each user in real time. Thus, ADROIT is expected to enable distribution of operations and to reduce the cost of operations by reducing the number of persons required to be in the center.

Hodges, Mark↗

ELM model simulations of Plum Island Ecosystems LTER low marsh site 2018-2020

Model simulations using the Department of Energy's Energy Exascale Earth System Model (E3SM) land model (ELM) with improved capabilities to represent vegetation response to salinity and inundation. The simulations were conducted for a tidal salt marsh at Plum Island Ecosystems Long Term Ecological Research (LTER) site near Rowley, Massachusetts, USA; the site is a low marsh dominated by Spartina alterniflora. The model was forced with site-specific meteorology, salinity and tidal cycles from 2018-2020. Four sets of model simulations are included and described below:1. Parameterization of the salinity response function. These simulations tested different combinations of values for optimal salinity and salinity tolerance.2. Model evaluation. This comparison conducted simulations using the default model, the salinity function only, the submergence function only, and both the salinity and submergence functions. 3. Salinity scenarios. These simulations used the 2018 salinity input data varied by -5 to +10 ppt salinity.4. Water level scenarios. These simulations used the tide height varied by -10 to +50 cm. These simulations were used to demonstrate how the salinity and submergence functions better represent carbon uptake by tidal salt marshes.The data package includes netCDF files used as forcing files for tide height and salinity, one for each year 2018-2020 at observed salinity concentrations, and an additional three forcing files in which salinity concentrations were varied 5 ppt lower, 5 ppt higher, and 10 ppt higher than the measured 2018 time series. Also included are python scripts for creating forcing files, plain text parameter and command files for running simulations, model outputs in netCDF format, and python scripts for visualizing outputs. Code for the modified E3SM model is archived in Sulman et al 2023 at doi:10.15485/1991625. More detail about files is provided in the README.md file.

54 ENVIRONMENTAL SCIENCES↗

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and uplink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and unlink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗

Hydra Rendezvous and Docking Sensor

The U.S. technology to support a CEV AR&D activity is mature and was developed by NASA and supporting industry during an extensive research and development program conducted during the 1990's and early 2000 time frame at the Marshall Space Flight Center. Development and demonstration of a rendezvous/docking sensor was identified early in the AR&D Program as the critical enabling technology that allows automated proxin~ity operations and docking. A first generation rendezvous/docking sensor, the Video Guidance Sensor (VGS) was developed and successfully flown on STS 87 and again on STS 95, proving the concept of a video-based sensor. Advances in both video and signal processing technologies and the lessons learned from the two successful flight experiments provided a baseline for the development of a new generation of video based rendezvous/docking sensor. The Advanced Video Guidance Sensor (AVGS) has greatly increased performance and additional capability for longer-range operation. A Demonstration Automatic Rendezvous Technology (DART) flight experiment was flown in April 2005 using AVGS as the primary proximity operations sensor. Because of the absence of a docking mechanism on the target satellite, this mission did not demonstrate the ability of the sensor to co~ltrold ocking. Mission results indicate that the rendezvous sensor operated successfully in "spot mode" (2 km acquisition of the target, bearing data only) but was never commanded to "acquire and track" the docking target. Parts obsolescence issues prevent the construction of current design AVGS units to support the NASA Exploration initiative. This flight proven AR&D technology is being modularized and upgraded with additional capabilities through the Hydra project at the Marshall Space Flight Center. Hydra brings a unique engineering approach and sensor architecture to the table, to solve the continuing issues of parts obsolescence and multiple sensor integration. This paper presents an approach to sensor hardware trades, to address the needs of future vehicles that may rendezvous and dock with the International Space Station (ISS). It will also discuss approaches for upgrading AVGS to address parts obsolescence, and concepts for modularizing the sensor to provide configuration flexibility for multiple vehicle applications. Options for complementary sensors to be integrated into the multi-head Hydra system will also be presented. Complementary sensor options include ULTOR, a digital image correlator system that could provide relative six-degree-of-freedom information independently from AVGS, and time-of-flight sensors, which determine the range between vehicles by timing pulses that travel from the sensor to the target and back. Common targets and integrated targets, suitable for use with the multi-sensor options in Hydra, will also be addressed.

Roe, Fred↗

Facilitating Analysis of Multiple Partial Data Streams

Robotic Operations Automation: Mechanisms, Imaging, Navigation report Generation (ROAMING) is a set of computer programs that facilitates and accelerates both tactical and strategic analysis of time-sampled data especially the disparate and often incomplete streams of Mars Explorer Rover (MER) telemetry data described in the immediately preceding article. As used here, tactical refers to the activities over a relatively short time (one Martian day in the original MER application) and strategic refers to a longer time (the entire multi-year MER missions in the original application). Prior to installation, ROAMING must be configured with the types of data of interest, and parsers must be modified to understand the format of the input data (many example parsers are provided, including for general CSV files). Thereafter, new data from multiple disparate sources are automatically resampled into a single common annotated spreadsheet stored in a readable space-separated format, and these data can be processed or plotted at any time scale. Such processing or plotting makes it possible to study not only the details of a particular activity spanning only a few seconds, but also longer-term trends. ROAMING makes it possible to generate mission-wide plots of multiple engineering quantities [e.g., vehicle tilt as in Figure 1(a), motor current, numbers of images] that, heretofore could be found only in thousands of separate files. ROAMING also supports automatic annotation of both images and graphs. In the MER application, labels given to terrain features by rover scientists and engineers are automatically plotted in all received images based on their associated camera models (see Figure 2), times measured in seconds are mapped to Mars local time, and command names or arbitrary time-labeled events can be used to label engineering plots, as in Figure 1(b).

Maimone, Mark W.↗

MicroShell Minimalist Shell for Xilinx Microprocessors

MicroShell is a lightweight shell environment for engineers and software developers working with embedded microprocessors in Xilinx FPGAs. (MicroShell has also been successfully ported to run on ARM Cortex-M1 microprocessors in Actel ProASIC3 FPGAs, but without project-integration support.) Micro Shell decreases the time spent performing initial tests of field-programmable gate array (FPGA) designs, simplifies running customizable one-time-only experiments, and provides a familiar-feeling command-line interface. The program comes with a collection of useful functions and enables the designer to add an unlimited number of custom commands, which are callable from the command-line. The commands are parameterizable (using the C-based command-line parameter idiom), so the designer can use one function to exercise hardware with different values. Also, since many hardware peripherals instantiated in FPGAs have reasonably simple register-mapped I/O interfaces, the engineer can edit and view hardware parameter settings at any time without stopping the processor. MicroShell comes with a set of support scripts that interface seamlessly with Xilinx's EDK tool. Adding an instance of MicroShell to a project is as simple as marking a check box in a library configuration dialog box and specifying a software project directory. The support scripts then examine the hardware design, build design-specific functions, conditionally include processor-specific functions, and complete the compilation process. For code-size constrained designs, most of the stock functionality can be excluded from the compiled library. When all of the configurable options are removed from the binary, MicroShell has an unoptimized memory footprint of about 4.8 kB and a size-optimized footprint of about 2.3 kB. Since MicroShell allows unfettered access to all processor-accessible memory locations, it is possible to perform live patching on a running system. This can be useful, for instance, if a bug is discovered in a routine but the system cannot be rebooted: Shell allows a skilled operator to directly edit the binary executable in memory. With some forethought, MicroShell code can be located in a different memory location from custom code, permitting the custom functionality to be overwritten at any time without stopping the controlling shell.

Werne, Thomas A.↗

Development and Flight Testing of an Adaptable Vehicle Health-Monitoring Architecture

Development and testing of an adaptable wireless health-monitoring architecture for a vehicle fleet is presented. It has three operational levels: one or more remote data acquisition units located throughout the vehicle; a command and control unit located within the vehicle; and a terminal collection unit to collect analysis results from all vehicles. Each level is capable of performing autonomous analysis with a trained adaptable expert system. The remote data acquisition unit has an eight channel programmable digital interface that allows the user discretion for choosing type of sensors; number of sensors, sensor sampling rate, and sampling duration for each sensor. The architecture provides framework for a tributary analysis. All measurements at the lowest operational level are reduced to provide analysis results necessary to gauge changes from established baselines. These are then collected at the next level to identify any global trends or common features from the prior level. This process is repeated until the results are reduced at the highest operational level. In the framework, only analysis results are forwarded to the next level to reduce telemetry congestion. The system's remote data acquisition hardware and non-analysis software have been flight tested on the NASA Langley B757's main landing gear.

Woodard, Stanley E.↗

What Can We Learn from One Billion Ground System Log Messages?

Shortage of log-based data in a ground system they have traditionally been the under achievers in a satellite ground system. This is due to several factors: Once log messages scroll out of view on the TTC event console window they are soon forgotten. Application and system log files are scattered across directories within a system, across a multitude of servers, and across one or more databases making access cumbersome. Typical tools to perform log file content searching are generally crude and typically only employed as part of trouble-shooting exercises.As we move towards satellite constellations and fleets and add even more status information, the number of messages keeps growing. One mission now estimates that they could generate 3,000,000 messages per day 1 billion per year - for the life of their mission. What to do with those 1 billion messages? That is the challenge. With the recent technological advances in the management of large data sets, text-based processing, and data analytics, there are now capabilities that we can provide to the ground system engineers and satellite operators to address what we postulate are missed opportunities. Advanced real-time log analysis can allow us to be less reactionary in favor of being more proactive. Analytics goals include the ability to: Identify root cause of unexpected events, failures or error conditions enabled by correlating disparate data. Detect security breaches attempts before they are successful. Help admins ensure IT resources continue running optimally. Identify trends and patterns that may indicate impending failures or error conditions for valuable assets before they happen. Compare satellites in a fleet or constellation in terms of number of alarms, number of command sent to them, etc.. Answer questions like "Are the operations support needs increasing over the past year?" or "Have we seen this combination of alarm conditions before?" But really, once the tools are readily available the users will start realizing what can be done with their new powers. In this presentation we will show the results of analyzing millions of actual mission operations log messages, how the results can be displayed to the user, and how new products now available as open source can be applied to the challenges of large scale time-tagged text-based mission operations messages. Flight operations team members believe that this is a powerful new option for how they assess overall system and space asset health. Technical descriptions of the design, tools, and storage will be provided. One billion messages? Bring'em on!

Orsborne, Sharon↗

Liquid-Propellant Rocket Engine Throttling: A Comprehensive Review

Liquid-Propellant Rocket Engines (LREs) are capable of on-command variable thrust or thrust modulation, an operability advantage that has been studied intermittently since the late 1930s. Throttleable LREs can be used for planetary entry and descent, space rendezvous, orbital maneuvering including orientation and stabilization in space, and hovering and hazard avoidance during planetary landing. Other applications have included control of aircraft rocket engines, limiting of vehicle acceleration or velocity using retrograde rockets, and ballistic missile defense trajectory control. Throttleable LREs can also continuously follow the most economical thrust curve in a given situation, compared to discrete throttling changes over a few select operating points. The effects of variable thrust on the mechanics and dynamics of an LRE as well as difficulties and issues surrounding the throttling process are important aspects of throttling behavior. This review provides a detailed survey of LRE throttling centered around engines from the United States. Several LRE throttling methods are discussed, including high-pressure-drop systems, dual-injector manifolds, gas injection, multiple chambers, pulse modulation, throat throttling, movable injector components, and hydrodynamically dissipative injectors. Concerns and issues surrounding each method are examined, and the advantages and shortcomings compared.

Casiano, Matthew↗