Overview
To rigorously test rocket engines, turbopumps, and full propulsion systems, leading aerospace teams leverage specialized application software to store, visualize, and automatically review telemetry data. All propulsion tests—hot fires, static fires, and integrated vehicle firings—feed telemetry into a centralized storage and visualization system, while automated data review applies consistent checks across all test environments, from Hardware in the Loop (HITL) to full-scale vehicle tests.
The Data Review Process
The data review process occurs for every single propulsion test, whether it’s a full-duration hot fire, a subscale combustion stability test, or a HITL simulation. Since all telemetry data is streamed into the same system and subjected to standardized checks, the majority (99.99%) of automated rules pass without issue. Many reports, especially from early-stage component-level tests, routinely auto-pass in the CI system. For these runs, telemetry flows into Sift, which ingests, stores, and reviews the data without a Responsible Engineer (RE) needing to manually inspect each dataset.
An RE only needs to review telemetry manually if the system flags an anomaly. The root cause investigation is rarely a linear process but involves a combination of:
- Plotting relevant data channels for combustion efficiency, injector performance, and chamber pressure fluctuations
- Searching historical annotations for previous instances of similar anomalies
- Creating custom visualizations from relevant raw channels, test stand logs, and derived telemetry data
- Correlating flagged anomalies with simultaneous events in the test environment
- Investigating the test asset performance through diagnostic tests on the HITL table or comparing against simulation data
- Sharing flagged failures with teammates for collaborative analysis
- Comparing current anomalies with historical propulsion test telemetry from similar test assets, software revisions, or test scenarios
- Attempting to reproduce the anomaly by re-running specific test conditions
- Searching associated documentation and the code base for potential software-induced errors
- Checking previous test reports and anomaly resolutions in the ticketing system
Once a root cause is determined, the RE implements a fix through one or more actions:
- Tune the data review rule to account for the newly surfaced edge or corner case,
- Update the vehicle software to fix a bug,
- Update the simulation to increase the fidelity, or
- Change the scenario that the test runner orchestrates.
By continually refining automatic anomaly detection, propulsion engineers gain deeper insight into engine performance and progressively remove the need for manual review.
Pre-Flight Test Campaign
Hardware Test and Integration
Component Flashing and Calibration
Each subcomponent—injectors, igniters, turbopumps—receives the latest firmware and undergoes automated calibration before integration. Although not the final flight firmware, this version ensures components are tested under flight-representative conditions. Test commands, executed via standardized test runners, send telemetry data to the unified storage system for real-time visualization and automated validation.
By integrating telemetry from HOOTL, HITL, and vehicle data, engineers gain deeper insights into vehicle behavior.
Calibration accounts for minor deviations in manufacturing tolerances, ensuring that pressure transducers, valve actuation timing, and flow rate sensors operate within expected ranges. These calibrations are logged and stored in a configuration repository for later integration and mission operations.
Subsystem Integration and Test
Once individual components pass qualification, they are integrated into full propulsion subsystems. The first critical subsystem validation is Polarity—a test ensuring that software controls correctly map to hardware responses. If an engine gimbal moves in the wrong direction or a turbopump cycles incorrectly, the test flags a fault. Like all prior stages, data is stored in the same telemetry system for automated review, with REs analyzing any failures.
The continuous data review process supports rigorous testing, from initial hardware checks to final pre-launch operations.
Vehicle in the Loop Test
Vehicle in the Loop Testing (VITL) ensures that integrated propulsion systems operate correctly under simulated flight conditions. This includes:
- Delay tests to measure response time between the flight computer’s throttle commands and actual thrust output
- Transient response evaluations for mixture ratio control, pressure regulation, and startup/shutdown sequences
- Full-duration mission scenarios, incorporating throttle changes, coast phases, and contingency maneuvers
As before, all data is fed into the unified telemetry storage system, and failures are root-caused before advancing to mission-level testing.
Day of Launch Checkouts
Before launch, final subsystem checkouts verify system readiness. No vehicle proceeds unless all propulsion-related tests—covering igniter functionality, propellant pressurization, and engine thrust vectoring—have either auto-passed or been investigated and dispositioned.
Mission control operators notify REs as soon as checkouts complete. Whether in mission control or remotely monitoring, propulsion engineers review flagged telemetry and certify the system for flight. Automated review eliminates the burden of manual verification, surfacing only anomalies requiring engineering intervention.
Software Test
Polarity
Before physical Polarity testing, flight software runs dry runs on HITL testbeds to catch errors. Failures flagged by automated checks are addressed before testing on integrated hardware. This ensures Polarity testing does not introduce new risks to the propulsion system.
Verification Events
Flight software must meet stringent regulatory requirements. Each software update affecting propulsion control logic is validated through Verification Event (VE) testing. This includes:
- Nominal and contingency hot-fire simulations
- Validation of "must work" and "must not work" safety-critical functions
- Regression testing for recent software modifications
Data from these tests is stored and analyzed in the same system as hardware tests, ensuring consistency across development.
A unified approach to telemetry ensures consistent rule application and comprehensive analysis across all testing stages.
Joint Test
Some software updates require verification in a joint test environment where a propulsion system interacts with external spacecraft or launch vehicle systems. Before full-scale Joint Testing, HITL dry runs with simulated assets verify software compatibility. Final Joint Tests physically connect hardware testbeds to evaluate real-world interactions under various failure scenarios.
VITL
VITL serves as the last integration event before final flight software release. It confirms parity between testbeds and flight hardware, ensuring all software-hardware interactions behave as expected under mission conditions. Only after full review and sign-off from subsystem REs does the propulsion system advance to final pre-flight certification.
Standalone Run for Records (R4R)
Standalone R4R tests validate full mission scenarios and worst-case propulsion failure modes using finalized flight configurations. These tests provide formal certification data to regulatory bodies, ensuring all propulsion functions meet safety and reliability requirements.
Joint Run for Records
Joint R4R tests simulate coordinated operations between multiple systems—such as booster and upper stage propulsion interactions. Unlike earlier tests relying on simulated counterparts, these tests physically integrate HITL assets to validate real-time interactions.
Green for Flight
The final test campaign, Green for Flight (GFF), runs hundreds of propulsion-specific test cases covering mission phases and failure scenarios. These include deep-dive evaluations of:
- Engine startup and shutdown sequences
- Propellant conditioning and pressurization logic
- Contingency scenarios, such as thrust vector actuator failures or pressure losses
Once all anomalies are dispositioned, the propulsion system receives final approval for flight.
“Prime” HITLs
By R4Rs and GFF tests, almost all of the configs have been reviewed, but some have not yet been updated in the code base. These “Day of Launch” (DOL) configs include final mass properties of the vehicle, final trajectory parameters, and others. After all these final DOL configs have been committed, a final set of subsystem checkout and “Prime” HITLs will be tested. “Prime” HITLs test all nominal mission scenarios using the exact software that will launch. Once all failures identified by the automated review tool have been dispositioned by all relevant REs, the flight software RE will make the software release for flight.
Want to dive into your specific use case and see Sift in action? Request a demo here.
