Simulate the Model Your Vendor Won't Show You
Ask a propulsion vendor for the model behind their thruster and you will get a performance curve, a data sheet, and a courteous no. They are right to refuse. The problem is what most integrators do next: they treat that refusal as permission to skip the simulation, and the two boxes meet for the first time on the integration bench, with most of the schedule already gone.
Every integrator wants high-fidelity models of the components they did not build. A satellite prime assembling a spacecraft from a dozen vendors needs to run the whole stack in software before any of it exists in aluminum. That means exercising the reaction wheels, the star tracker, the propulsion system, and the power electronics as behaviors, not as numbers on a page. The fidelity of that simulation is the fidelity of the models feeding it, and the most important ones belong to someone else.
The vendors who built those components will not hand the models over. A thermal model of a flight computer, or the control logic inside a thruster valve, is the product, refined across years of test campaigns and paid-for failures. Ship the model and you have shipped the thing itself. So the integrator asks for fidelity, the vendor protects its work, and both are behaving correctly. The standoff is real, and it does not resolve by one side giving in.
A data sheet is not a model
What crosses the boundary today is a specification. The vendor sends the operating range, a handful of performance points, an interface control document, and if the integrator is lucky a spreadsheet of measured values. None of that runs. To put the component into a software-in-the-loop rig, someone on the integration side writes a stub that reproduces the numbers on the sheet. That stub captures the steady-state points the vendor chose to publish and nothing else. It agrees with the real hardware where the data sheet does, and it wanders everywhere the data sheet stays silent, which is the off-nominal territory the simulation exists to explore. A thruster that behaves cleanly at its rated chamber pressure can do something stranger during a cold start or a valve-chatter transient, and the stub built from the catalog holds no opinion about either.
The vendor is right to keep the model shut
Push harder and the request turns into: send us your Simulink model, or your source. No serious vendor agrees to that, because the internal model is where the advantage lives. A reaction-wheel supplier's friction-and-jitter model is the reason their wheel outsells the next one. Handing it to a prime who also buys from three competitors is not a data exchange, it is a transfer of the asset. We think the integrators who frame vendor secrecy as obstruction have it backwards. The vendor should say no. The real task is to get fidelity across the boundary without asking anyone to expose what they spent a decade building.
Automotive shipped the answer fifteen years ago
Carmakers faced the same problem and settled it. An OEM integrates engine controllers, brake systems, and battery packs from Tier-1 suppliers who guard their models as closely as any aerospace vendor. In 2010 the MODELISAR project produced the Functional Mock-up Interface, a standard the Modelica Association has maintained since 2011, with a major revision in 2014 and another in 2022. It defines a Functional Mock-up Unit: a zip file holding a compiled model behind a small, standard interface, plus a description of its variables. A supplier compiles its controller into a binary FMU and ships that. The carmaker drops the FMU into its own co-simulation and runs it against the rest of the vehicle. The model executes at full fidelity. The internals stay compiled, unreadable, and the supplier's property. Fidelity crosses the boundary and the IP does not.
An executable model the integrator can run but never read is the deliverable aerospace still forgets to ask for.
Aerospace owns the pieces and skips the habit
Space is not short on the technology. ESA standardized simulation model portability as SMP2 in 2005, now the ECSS standard for the job, and models built to it already move between simulators such as ESA's SIMULUS and Airbus's SimTG. Co-simulation frameworks are mature. The standards for packaging a portable, executable model exist and carry flight-program pedigree. What the industry mostly skips is writing the vendor contract so that the deliverable is one of those models rather than a document. The statement of work still asks for an ICD and a performance report, both of which describe the component and neither of which runs. A procurement template drafted before portable models were routine keeps specifying the artifact from that era, and the engineers downstream inherit a PDF where they needed an executable.
Write the model into the contract
When a thruster vendor owes a validated executable model, with its interface, its valid ranges, and the off-nominal regimes the customer named in the statement of work, the prime runs the real behavior in simulation months before the hardware ships. A mismatch that used to surface on the bench surfaces on a workstation, while there is still schedule and budget to absorb it. The vendor delivers the sealed model once and stops answering the same clarifying email for a year. The integrator stops guessing at behavior the vendor characterized long ago. Nobody opens their internals, because the executable was never a request to.
The model your vendor will not show you is the one your simulation most needs, and the reason you cannot have it is a habit rather than a law of physics. Automotive broke that habit by making the sealed, executable model the thing suppliers deliver. Space has the standards, the tools, and the flight history to do the same. What it hands its integrators instead is a folder of PDFs describing components that nobody can run until the week they finally have to.
