You can use the following five approaches to protect the intellectual property of a Simulink model:
- Protected Model
- Shared Library
- Standalone FMU
- S-Function Target
- Read/Write Access for Subsystems
For an overview of requirements and capabilities for each option, see the table at the bottom of the page.
1. Protected Model
Protected Models are the preferred solution for sharing models with other Simulink users without revealing its content. The third party receiving the protected model (.slxp file) can reference it from their Simulink model, without being able to edit the contents. If enabled by the author, the third party can generate code from the protected model.
The protected model approach has many advantages:
- Easy to use. The protected model offers a very familiar interface to someone used to working with model references.
- AES-256 encryption can be applied to the file contents by enabling password protection.
- The author can choose to share a read-only version (web view) of the protected model.
- From R2018b onwards, protected models are forward compatible.
- From R2020a onwards, you can attach a digital signature to a protected model.
Note that protected models are platform-specific. If a protected model has been created on Windows, it cannot be run by the third party if they use Linux or macOS.
For more information, see Protect Models to Conceal Contents.
2. Shared Library
Another recommended way is to use the shared library system target file (ert_shrlib.tlc) to generate a universal shared library (.DLL/.SO) for a model or subsystem. One main advantage of this approach is that a shared library can be run in a system simulation outside of Simulink.
For more information, see Package Generated Code as Shared Libraries.
3. Standalone FMU
From R2020b, you can export a standalone FMU from a model which creates a .fmu file consisting of a compiled binary of the customers model and a .XML file consisting of the interface (inputs, outputs and parameters). This option requires a Simulink Compiler license. The FMU is release agnostic but it is limited to simulation in the same environment it is generated in unless they compile the binary for other environments.
For more information, see Export Simulink Models to Functional Mock-up Units.
4. S-Function
In R2013b and earlier it was recommended to use the S-Function target to generate S-Function code from your model or subsystem and then build it into a MEX file. Note that generating such an S-Function also requires a Simulink Coder license. The main drawback compared to protected models is that the S-Function target has no built-in option to apply encryption. Additionally, Protected Models and Shared Libraries increase execution efficiency and facilitate code reuse, while MEX files built from S-function target code do not.
For more information, see Use S-Function Target for Model or Subsystem.
5. Read/Write Access for Subsystems
This is the least secure, but easiest method, and requires no additional license or matching platform. By setting the read/write permissions in the Subsystem block parameters to 'NoReadOrWrite', no action will occur when a user double clicks on it. However, the permission can be changed by any user. This method deters editing rather than truly concealing the contents of the model.
For more information, see the section Specify Subsystem Read/Write Permissions.
Overview of Requirements & Capabilities:
Required Products for Export | Cross-Platform Support | Code Generation Support | Supported MATLAB Releases | |
Protected Model | Simulink Coder | No | Yes, if enabled by Protected Model creator | R2014b and later |
Shared Library (ert_shrlib.tlc) | Simulink Coder & Embedded Coder | No | Limited | Any |
Standalone FMU | Simulink Compiler | Yes, when exported with source code (requires Simulink Coder) | Limited | R2020b and later for export |
S-Function | Simulink Coder | No | No | Any |
Read/Write Permissions | - | Yes | Yes | Any |
