Protect Models to Conceal Contents

When you want to share a model with a third party without revealing intellectual property, protect the model. Protecting a model conceals the implementation details of the original model by compiling it into a referenced model. The protected model includes derived files to support the optional functionalities that you specify.

When you protect a model by using Simulink^® Coder™, you can allow the user of the protected model to:

Simulate a model that includes the protected model in normal, accelerator, rapid accelerator, or external mode.
Open a read-only web view of the model, including model contents and block parameters. Creating a read-only web view of the model requires a Simulink Report Generator™ license.
Generate C and C++ code for a model that includes the protected model.
Generate HDL code for a model that includes the protected model, if you have an HDL Coder™ license.
Generate code for the protected model through the standalone interface, if you have an Embedded Coder^® license and specify an ERT-based system target file for the model.

You can optionally password-protect each option. If you choose password protection for one of these options, the software protects the supporting files by using AES-256 encryption. Before you create a protected model, consider how the third party will use the model and these Best Practices for Creating Protected Models.

When you create a protected model:

Simulink Coder creates and stores a protected version of the model in a file that has the same name as the source model, with an .slxp extension.
The original model file, with the .slx extension, does not change. If you protect the model through a Model block, that Model block does not change.
Optionally, Simulink Coder creates a project archive (.mlproj) that contains the protected model, a harness model for the protected model, and additional supporting files.

This example shows how to create a protected model from a referenced model for read-only viewing, simulation, or code generation.

Prepare the Parent Model

Optionally, configure the Model blocks in the parent model to refer to the original referenced model. This step prevents the Model blocks from becoming protected references when you create the protected model.

Open the parent model that references the model you want to protect. For this example, open the model named sldemo_mdlref_basic.
For each Model block, open the Block Parameters dialog box and specify the extension .slx in the Model name field.
When both the model and the protected model exist in the same folder, .slxp takes precedence over .slx. If you do not specify an extension, the original Model block refers to the protected model instead of the original model.
Click OK.

Protect the Referenced Model

In the sldemo_mdlref_basic model, click any of the three Model blocks. On the Simulink toolstrip, on the Model Block tab, click Protect.

The Protected Model Creator opens.

Protected Model Creator opened for sldemo_mdlref_counter

On the General tab, specify the functionality to support.

Select Simulation and Code generation. These options allow the protected model user to simulate and generate code for a model that references the protected model. If you want to password-protect the functionality of the protected model, enter a password with a minimum of eight characters. Each option can have a unique password.
Tip
The Protected Model Creator caches your settings for a model during a MATLAB^® session. If you close and reopen the dialog box, the settings persist. Passwords and tunable parameter selections are not cached. To restore the default settings, click Reset. (since R2023b)
If you have an Embedded Coder license and the model specifies an ERT-based system target file, for example, ert.tlc, the Code interface field is visible.
In this example, sldemo_mdlref_basic does not specify an ERT-based system target file, therefore the Code interface options are not available in the Protected Model Creator.
From the Content type list, select Obfuscated source code to conceal the source code purpose and logic of the protected model. For more information on the model protection options, see Content type.
Optionally, specify a custom text tag in the Identifier tag box. For example, to store file provenance information in a protected model, specify the job number, Git™ commit, or continuous integration system tag associated with creating the protected model. (since R2024b)

On the Simulation Options tab, specify the parameters that users of the protected model can tune during simulation.

To compile the model and list tunable parameters, in the Tunable parameters for simulation section, click Refresh (since R2023b).
Select the parameters that you want the protected model user to be able to tune during simulation.
In this example, sldemo_mdlref_basic does not have any tunable parameters.
Note
For code generation, parameters with non-auto storage classes are tunable. For more information, see Storage Classes for Parameters and Signals Used in Model Blocks.

On the Save Options tab, specify where to save the protected model, whether to save the protected model in a project with its supporting files, and whether to create a harness model.

In the Destination folder box, specify the folder path for the protected model. The default value is the current working folder.
To automatically collect, create, and package supporting files with the protected model, select Package protected model with dependencies in a project.
Note
Before sharing the project, check whether the project contains the necessary supporting files. If supporting files are missing, simulating or generating code for the related harness model can help identify the missing files. Add the missing dependencies to the project and update the harness model as needed.
Selecting Package protected model with dependencies in a project selects Create harness model for protected model. The harness model is included in the project and provides an isolated environment for the Model block that references the protected model.

To further customize your protected model, you can:

Specify a custom obfuscator for code obfuscation. See Specify Custom Obfuscators for Protected Models.
Specify multiple code generation targets. See Create Protected Models with Multiple Targets.
Define callbacks for the protected model. See Define Callbacks for Protected Models.

To create the protected model, click Create.

A project archive (.mlproj) that contains the protected model, harness model, and supporting files appears in the specified destination folder. To test the protected model, extract the contents of the project archive by double-clicking it in the Current Folder browser and specifying the destination folder. Alternatively, right-click the project archive. Then, click Extract Here. The project opens, and the extracted files are in a new folder named after the project archive.

You can test the protected model to compare it to the original model. For more information, see Test Protected Models.

To use the protected model in a model hierarchy, reference it through a Model block such as the one included in the harness model. The Simulation mode for Model blocks that reference a protected model is set to Accelerator. You cannot change the mode. For more information, see Reference Protected Models from Third Parties.

Other Methods of Protecting Models

To create a protected model from the top model in the current model hierarchy, use one of these options:

On the Simulink Toolstrip Simulation tab, click the Save button arrow, and then select Protected Model.
On the Simulink Toolstrip C Code tab, click the Share button arrow, and then select Generate Protected Model.

To create a protected model programmatically, use the Simulink.ModelReference.protect function.

Protected Model Report

When you create the protected model from the Simulink Editor, a protected model report is generated and is included as part of the protected model. For this example, to view the protected model report, double-click the protected model or right-click the protected-model badge icon on the block in the harness model and select Display Report.

Protected model report for sldemo_mdlref_counter

The report contains:

A Summary, including the following tables:
- Environment, providing the Simulink version and other product versions and the platform used to create the protected model.
- Supported functionality, reporting On, Off, or On with password protection for each possible functionality that the protected model supports. If you configure your protected model for multiple targets, this table includes a list of supported targets.
An Interface Report, including model interface information such as input and output specifications, exported function information, interface parameters, and data stores.

The report does not contain other sections that appear in a code generation report for non-protected models, such as a code metrics report and traceability report, because these reports include more information about the model design.

To get information about the protected model programmatically, use the slxpinfo function.

Protected Model Requirements and Limitations

When you create a protected model, consider these following requirements:

You must have a Simulink Coder or HDL Coder license to create a protected model.
If you protect a model containing blocks that require another product license in addition to Simulink, using the protected model in a separate MATLAB session requires only a Simulink license. However, for models containing Simscape™ blocks that employ a variable-step solver set to VariableStepAuto or daessc, a Simscape license is also required.
The model must be available on the MATLAB path.
The model uses the configuration that is active during protection. You cannot change the configuration of a protected model.
If the model contains variants, the protected model includes only the variant that is active during protection.
The model protection process does not preserve callbacks. For more information on creating callbacks for use with a protected model, see Define Callbacks for Protected Models
Do not rename the protected model or change its suffix. If you do so, the model is unusable until you restore its original name and suffix.
Use a unique name for the model and for models that it references. If a protected model references a model that shares a name with either a different protected model or a different model within the hierarchy of another protected model, there are limitations for using the protected models. If a top model references two protected models that have such a naming conflict, you cannot protect the top model, generate code for the top model, or simulate the top model in software-in-the-loop (SIL), processor-in-the-loop (PIL), or rapid accelerator modes.
If your model includes a non-inlined S-function, use a unique name for the .MEX file. If there is a name conflict with a different .MEX file on the MATLAB path, you cannot simulate the protected model.
To create a protected model that can run in Simulink Real-Time™, install the Speedgoat^® I/O Blockset and set the Code Generation > System target file configuration parameter to correspond to the target computer (for example, speedgoat.tlc) before protecting the model.

The model must also meet the requirements listed in Model Reference Requirements and Limitations.

Code Generation Requirements and Limitations

To create a protected model that supports code generation, the model being protected must meet these requirements:

The model must use normal, accelerator, software-in-the-loop (SIL), or processor-in-the-loop (PIL) modes and a single target.
The model must not include noninlined S-functions.
The model must not have the Code Generation > Verification > Measure function execution time configuration parameter selected. If this option is selected when you protect a model, the software turns off the parameter and displays a warning.
Protected referenced models must support code generation without password protection.

The model must be compatible with the Content type of each protected referenced model. This table provides compatibility information.

Code Generation Content Type Compatibility

Protected Parent Model Content Type	Compatible Protected Referenced Model Content Types
`Binaries`	`Binaries` `Obfuscated source code`
`Binaries` with `'ObfuscateCode'` set to `'false'`	`Binaries` `Binaries` with `'ObfuscateCode'` set to `'false'` `Obfuscated source code` `Readable source code`
`Obfuscated source code`	`Obfuscated source code`
`Readable source code`	`Obfuscated source code` `Readable source code`

When the Content type of the protected parent model and protected referenced models do not match, code generation applies the Content type that provides the higher level of protection. For example, a protected parent model set for Binaries generates Binaries for protected referenced models that are set to Obfuscated source code. A protected parent model set for Readable source code generates Obfuscated source code for protected referenced models that are set to Obfuscated source code.

To avoid an error during code generation of a model that includes a protected model:

The protected model name must be unique from other model names in the same model reference hierarchy.
The interfaces must match.
The parameters must be compatible.

Nested Protected Model Requirements and Limitations

To enable a recipient of your protected model to protect a model that references it, your protected model must:

Support accelerator mode. You must select Simulation in the Protected Model Creator or set 'Mode' to 'Accelerator' or 'CodeGeneration' using the Simulink.ModelReference.protect function.
Use the default 'CodeInterface' setting: 'Model reference'.
Not use password protection for simulation.
Not have callbacks.
Support without password protection the operations that the protected parent model is intended to support.
Use a Content type that is compatible with the intended Content type of the protected parent model if the protected parent model is intended to support code generation. For a list of compatible Content type options, see the table in the preceding section.
Use the same compiler as the protected parent model is intended to use.
Not reference a model that shares a name with either a different protected model or a different model within the hierarchy of another protected model.

If the model that you want to protect references a protected model, the referenced protected model must meet the preceding requirements.

When you protect a model that references a protected model, you must specify the tunable parameters of the referenced protected model as tunable for the model you are protecting.

Note

A protected model that you create with the HDL code generation option selected allows encryption and support for simulation and HDL code generation from a model that references the protected model. You cannot obfuscate the HDL source code, have callbacks, or use nested protected models with this option. To learn more about HDL code generation limitations, see Protected Model Restrictions for HDL Code Generation (HDL Coder).