You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the implementation of full support for controllers in RocketPy (see issue #274), there will be a need to integrate RocketPy with commonly used control system design tools, such as Simulink.
Therefore, this issue proposes the possibility of using RocketPy as one or more Simulink blocks.
Requirements
A Simulink block shall be created, based on, for example, a MATLAB Function block. Such MATLAB Function shall be responsible for running RocketPy under the hood. As already known, RocketPy can already be used in MATLAB. See the useful links below for more info.
The end-user should not need to know how to code in Python nor how to use Python.
An example with detailed documentation must be created.
Proposed Milestone
This feature should be implemented in a major release with full support for controllers.
RocketPy already documents calling its Python objects from MATLAB, but a Simulink integration needs a narrower real-time contract than the current interactive workflow. I suggest an RFC comparing three adapters:
Adapter
Main benefit
Main constraint
MATLAB System block calling Python
Smallest implementation and closest to the existing MATLAB workflow
Python lifecycle and call latency must be controlled
C/C++ S-function
Strong control over sample time and data layout
Requires a stable native ABI and a separate build/toolchain
MATLAB/Simulink bridge to a separate Python process
Isolates Python failures and dependencies
Adds transport, synchronization, and process-management complexity
For a first milestone, I recommend a deterministic discrete-step Python contract and a MATLAB System block adapter. The contract should be usable without MATLAB so its behavior can be tested in public CI.
The minimum interface should define:
one owner for the simulation state;
a fixed SI-unit input/output schema;
initialization, step(t, input), and shutdown operations;
a declared sample time with rejection of out-of-order or duplicate steps;
how solver errors and Python exceptions cross the boundary; and
the supported RocketPy, Python, MATLAB, and Simulink version matrix.
The first acceptance case can exchange a small deterministic state vector at a fixed sample time and compare the Simulink trace with a Python reference trace. Python-side contract tests should cover sample-time enforcement, state ownership, units, and failure propagation. Because MATLAB/Simulink cannot normally run in this project's public CI, any proprietary-side verification should report the exact product versions and commands rather than being represented as automated coverage.
If maintainers prefer an S-function or process bridge, the same transport-neutral step contract can remain the first deliverable. I can draft that schema once the adapter direction and supported product versions are chosen.
@ting-hong-shieh we need time to evaluate the possible architecture solutions. There are many PRs being opened to our repo right now and we need time to handle everything. I hope you understand that.
Activity
[-]Simulink Integration[/-][+]ENH: Simulink Integration[/+]ting-hong-shieh commentedon Aug 14, 2026
RocketPy already documents calling its Python objects from MATLAB, but a Simulink integration needs a narrower real-time contract than the current interactive workflow. I suggest an RFC comparing three adapters:
For a first milestone, I recommend a deterministic discrete-step Python contract and a MATLAB System block adapter. The contract should be usable without MATLAB so its behavior can be tested in public CI.
The minimum interface should define:
step(t, input), and shutdown operations;The first acceptance case can exchange a small deterministic state vector at a fixed sample time and compare the Simulink trace with a Python reference trace. Python-side contract tests should cover sample-time enforcement, state ownership, units, and failure propagation. Because MATLAB/Simulink cannot normally run in this project's public CI, any proprietary-side verification should report the exact product versions and commands rather than being represented as automated coverage.
If maintainers prefer an S-function or process bridge, the same transport-neutral step contract can remain the first deliverable. I can draft that schema once the adapter direction and supported product versions are chosen.
Gui-FernandesBR commentedon Aug 14, 2026
@ting-hong-shieh we need time to evaluate the possible architecture solutions. There are many PRs being opened to our repo right now and we need time to handle everything. I hope you understand that.