Run your Simulink models & libraries in Python.
-
Running software-in-the-loop tests with Simulink becomes time consuming with Matlab & Simulink overhead. There are ways to reduce it (Model reference, etc) however nothing has shown to be as fast as a precompiled shared library.
-
Python has a very mature set of tools and packages to automate testing.
-
Testing can be distributed to machines without Matlab/Simulink licenses.
-
There are more and more Python developers. Being able to hand off a Simulink Library for further use there is a good feature.
- Use Python and it's ecosystem to run complex Simulink models.
- Use Python &
pytest
to run Software-in-the-Loop (SIL) tests on Simulink subsystems. - Give Simulink algorithms to developers without Matlab/Simulink licenses to use.
- Use GitHub/GitLab actions and Python to automate testing in the cloud.
- Start a programming language war at your company.
This repository is a set of instructions, with examples, on how to create a Pythonic wrapper for Simulink models. It is not a turnkey Python module to do this:
import simulinkdll
simulinkdll.run("my_model.slx")
do_stuff()
For a given library or model configuring the Python should only need done when the Simulink Parameters/Signals change. The end developer will then be able do a import simulink_model
, but it takes development time.
- Create a shared library in Simulink.
- Create Python representations of all items in the header file.
- Open the shared library (
.dll
,.so
) in Python and run the model.
- For demonstrating minimal dll functionality and the steps required to run a model in Python.
- Demonstrate implementions of
SimulinkGlobal
vsExportedGlobal
inSimulink.Parameter
andSimulink.Signal
variables.
A simple discrete transfer function. Compiled with a 1st order low pass filter.
There are two example notebooks for Example 2.
- Simple Example - A simple low-level ctypes wrapper.
- Pythonic Example - Use Python syntactic sugar to create a high level TransferTF python class to interact with the model. Adds datalogging and pandas integration.
-
Example 2 also contains sample
pytest
tests in thetests
directory. This demonstrates how you can usepytest
to test Simulink models. Sample test results are shown shown in Example2/test_results.md. -
Tests can be run on GitHub actions as well. The project now includes comprehensive CI/CD workflows:
- CI Pipeline:
.github/workflows/ci.yml
- Multi-platform testing across Python 3.9-3.12 - Build Pipeline:
.github/workflows/build.yml
- Simulink model compilation - Release Pipeline:
.github/workflows/release.yml
- Automated releases
- CI Pipeline:
Adapted from Mathworks's Simulation of a Bouncing Ball
Running a Simulation in Simulink also has some overhead. By compiling the model to a shared library and executing it, this overhead is eliminated.
bouncing_ball_benchmark.m
benchmarks the model by testing increasingly smaller time steps. The model was then compiled and tested in Python and the corresponding times are recorded below.
Time Step | Simulink Duration (s) | Python Duration (s) |
---|---|---|
1e-4 | 0.5905 | 0.06 |
1e-5 | 1.0461 | 0.61 |
1e-6 | 8.1991 | 6.08 |
1e-7 | 78.9901 | 60.18 |
- Python 3.9+
- Required packages:
pip install -r requirements.txt
# Install dependencies
make install
# Run comprehensive tests
make test-all
# Test individual examples
python test_all_examples.py
# Run Example2 tests with pytest
cd Example2 && python -m pytest tests/ -v
# Build all missing shared libraries for Linux
make build-all-so
# Build specific example
make build-example1-so
This project includes comprehensive CI/CD automation for building and testing Simulink models.
The project uses GitHub Actions for automated building and testing:
- Triggers: Push to main/develop, pull requests
- Features:
- Multi-platform testing (Ubuntu, Windows)
- Multi-Python version testing (3.9-3.12)
- Automatic .so file generation for Linux
- Comprehensive example testing
- Linting and validation
- Artifact upload for generated .so files
- Triggers: Changes to Simulink models (.slx, .mdl, .m files)
- Features:
- Automatic .so file generation
- Build validation
- Artifact creation and upload
- Triggers: Changes to source files, manual dispatch, releases
- Features:
- Dedicated .so file generation
- Library verification and testing
- Automatic GitHub releases with .so files
- Long-term artifact storage (90 days)
The .so files are automatically generated in GitHub Actions whenever:
- Source files are modified
- A pull request is created
- A release is published
You can also manually trigger the workflow using the "workflow_dispatch" trigger.
This project also serves as a proof of concept for using CI/CD devops techniques with Simulink Models. There is a Jenkinsfile
that will build each of the examples and archive the artifacts:
- shared library (
.dll
) - header files (
.h
)
Jenkins Pipeline screenshot:
Jenkins Artifacts screenshot: