Propulsion Engineering Requirements Traceability: One Injector Change

A hot-fire engineer pulls last month's test report to prepare for a design review and notices something off. The injector in the test article has a different face-plate orifice pattern than the one in the current CAD release. Nobody filed anything wrong. The designer opened a ticket, the change was approved in a Thursday meeting, and the model was updated the next week. The hot-fire data sat in a shared drive folder, labeled by date.

That gap is where propulsion programs lose weeks. Thrust, chamber pressure, mass and thermal margin are all coupled through the injector. Change the element pattern and you change mixing, combustion stability, and the heat flux the chamber wall sees. Test evidence collected before that change may no longer apply to the design you are about to fly.

This article walks through one injector change on a liquid engine program and follows the trace: from the requirement, to the CAD diff, to the hot-fire evidence, through design review and ECO. It isn't a tools list. It shows what a connected trace looks like in a propulsion engineer's daily work, and what breaks when it's missing.

The injector change that quietly invalidated last month's hot-fire

Picture a pressure-fed liquid engine in qualification. The requirement set is ordinary: thrust of a stated value at nominal chamber pressure, a mass ceiling for the engine assembly, and a minimum thermal margin on the chamber wall during steady-state burn. The injector is a showerhead-to-impinging hybrid, and the team has run a short hot-fire series that produced clean data.

Then a manufacturing engineer flags a drilling problem on the face plate. Two rows of orifices sit too close together for the available tooling, so the designer shifts the pattern and trims the face-plate thickness to recover mass. It's a small, sensible change. The CAD diff is a few dozen features.

But the thinner face plate runs hotter. The shifted orifices change local mixture ratio near the chamber wall. Both effects land on the thermal-margin requirement, and the mixture shift can move chamber pressure oscillation behavior too. The hot-fire series that "proved" thermal margin was run on the old geometry. That evidence is now attached to a design that no longer exists.

The engineer didn't make a bad change. The link between the requirement, the geometry and the test result was a human memory, and that's what failed. Test evidence is only valid for the configuration it was collected on. If your system can't say which injector revision produced which hot-fire data, you don't have verification. You have a folder of files.

Where propulsion requirements actually live: CAD, spreadsheets and test data

Ask where a propulsion requirement lives and you get three answers. The text lives in a requirements document or tool. The numbers that decide whether it is met live in spreadsheets: performance models, thermal margin calculations, mass rollups. The proof lives in test data, often telemetry from the stand. And the geometry that all three depend on lives in CAD.

Those four places drift apart because each updates on its own schedule. A mass rollup spreadsheet gets refreshed before a review, not when the model changes. A thermal margin calc is rerun when someone remembers. Telemetry is filed after the campaign, and the filename carries a date rather than a configuration.

A propulsion requirement is not a sentence. It is a sentence plus the CAD that implements it, the analysis that bounds it, and the test that demonstrates it.

Traceability in this setting means keeping those four things pointed at each other. Verification methods (test, analysis, inspection, demonstration) each produce evidence, and each piece of evidence needs a requirement on one side and a design configuration on the other. For thermal risk specifically, see how thermal requirements traceability holds up when the mechanical design moves.

Tandem treats this as one graph rather than four documents. Requirements sit in a parent and child hierarchy, system architecture nodes carry attributes such as mass, and CAD changes, reviews and validation evidence connect to both. The injector change in our example touches nodes in all of them, which is why it needs to be visible in one place.

Tracing a change through CAD: before/after diff, affected requirements and system interfaces

Start with the diff. A propulsion engineer reviewing the face-plate change needs to see what moved without opening two assemblies side by side and eyeballing them. Tandem produces a before/after 3D CAD diff with a plain-language summary of the change, along with the requirements and annotations it affects. For our injector, the summary names the shifted orifice rows and the reduced plate thickness, and the affected list surfaces the thermal-margin and mass requirements.

The second step is interfaces. An injector doesn't sit alone. It mates to the chamber, the manifold, the igniter, and the feed system. Tandem's system architecture module models systems, subsystems and components as nodes with interfaces between subsystems, so a change to the injector node shows which neighbors depend on it. Thickness changes can move a bolt pattern or a seal land. Orifice changes can shift flow coefficients the feed system analysis assumed.

Third, attributes. Mass is the clean example. If the injector node carries a mass attribute fed from CAD or a spreadsheet, the engine-level mass requirement can be checked against the new value rather than against a number someone typed last quarter. Tandem verifies requirements continuously against live attributes from CAD, spreadsheets and telemetry, so the mass check updates when the geometry does.

This is the same discipline the structural requirements traceability guide describes, applied to a thermal and performance-coupled part. The tool doesn't decide whether the thinner plate is acceptable. It makes sure nobody can approve the change without seeing what it touches. For CAD, Tandem has direct plugins for SolidWorks, Onshape, CATIA, NX and Fusion, and its Watch function records a CAD session and groups feature-tree actions into described design goals, so the reason for the change travels with the geometry.

Keeping test evidence attached: telemetry-fed attributes, test cases and continuous requirement verification

Now the part that burned us in the opening scene: the hot-fire data. The fix is to stop treating test results as files and start treating them as evidence tied to a requirement and a configuration.

In Tandem, test case management and test execution link to requirements, and validation evidence is stored in the same system as design intent. Telemetry can feed attributes directly. Tandem connects to Nominal for telemetry, works alongside test and telemetry platforms such as Sift and Revel, and Excel and Google Sheets cells can act as live attributes. So a peak wall temperature from the hot-fire series becomes an attribute on the chamber or injector node, and the thermal-margin requirement is checked against it.

What changes is the behavior when geometry moves. Because the requirement is verified against live attributes, a CAD change that touches the injector can flag the thermal-margin requirement for re-verification instead of leaving a green status that was earned on old hardware. This is the same pattern covered in tooling change after design freeze: the change doesn't erase the old evidence, it marks what must be re-earned.

For propulsion, build your test cases with this in mind. Each hot-fire test case should name the requirement it addresses, the hardware configuration it ran on, and the telemetry channels that produce the pass or fail number. Short-duration tests that only bound ignition transients are not evidence for steady-state thermal margin, and the test case should say so.

When an anomaly shows up on the stand, the same links work backward. A test anomaly report can trace a pressure oscillation to the requirement it threatens and the design change that preceded it. That's the difference between a two-hour investigation and a two-week one.

Design reviews and ECOs that carry the trace with them

A trace that lives only in the engineer's workspace dies at the first review. Reviews are where propulsion leads, structures, thermal and test engineers all look at the same change, so the trace has to be visible there.

Tandem's design reviews run in a browser-based 3D viewer that needs no CAD license, which matters when the thermal analyst or test lead doesn't have a seat. Annotations sit directly on geometry, with replies, mentions, and Slack or Teams notifications. A manufacturing engineer can leave feedback on the face-plate drilling right on the orifice rows, and that comment surfaces inside the designer's CAD tool, linked to the related requirements. In our scenario, the drilling constraint and the thermal consequence end up in the same conversation instead of two separate ones.

For formal gates, bring evidence rather than slides. A test readiness review should show which requirements each planned hot-fire verifies and which configuration the article matches. A critical design review package should show the injector change, its affected requirements, and the evidence status after the change.

Then the ECO. Tandem generates ECOs, ECNs and engineering documentation from captured CAD changes, in your own templates. Because the change record already carries the diff, the affected requirements and the review history, the ECO comes out of the trace instead of being a separate writing task done from memory. Pair it with a change control board that approves against the full impact, not the designer's summary. If the CCB approves a change without seeing the thermal-margin requirement flagged, the process failed before the engineering did.

A starting checklist for your next test campaign

The engineering judgments stay with you: the thermal model, the orifice sizing, whether the new plate thickness is acceptable, and the geometry work in your CAD system. What the trace does is make sure those judgments are made with the right information and that the evidence follows the hardware.

Before your next test campaign, work through this list:

1. Name the configuration. Every hot-fire test case states the exact injector and chamber revision on the test article.

2. Link tests to requirements. Each test case points at the thrust, chamber pressure, mass or thermal-margin requirement it verifies, with the verification method stated.

3. Feed numbers, don't retype them. Put peak temperatures, mass values and chamber pressure results into attributes sourced from telemetry, spreadsheets or CAD.

4. Define re-verification triggers. Decide up front which CAD changes (orifice pattern, plate thickness, material) force a retest and which only need analysis.

5. Review the diff, not the description. Require the before/after geometry and affected-requirement list in the review package.

6. Generate the ECO from the change record. If someone is writing it from memory, the trace isn't doing its job.

7. Audit one old test. Pick last month's hot-fire and ask whether you can prove which design it applies to.

Item seven is the uncomfortable one. Do it first.

Conclusion

Propulsion engineering requirements traceability isn't paperwork you do after the engine works. It tells you, the day an injector face plate changes, which hot-fire results still count. Run the item seven audit on your last campaign this week. If you can't name the configuration behind each result, connect your requirements, architecture, CAD changes and test evidence before the next burn, not after. Tandem links the before/after CAD diff to affected requirements, attaches telemetry-fed attributes and test cases, and carries the trace into design reviews and ECOs. Book a demo and bring one real injector or chamber change from your own program. We will trace it end to end.