Best Practices for Creating Protected Models

When you want to conceal the implementation details of a model that you share with a third party, create a protected model. Instead of including your original model files, the protected model includes derived files to support the functionalities that you specify. To create a protected model that supports functionalities that your user requires and that includes minimal information about your model, follow these best practices. The settings that you choose for the model before and during protection specify what the user of the protected model can do with it. Consider the trade-offs of different design options. To support additional functionalities, the protected model must include more content and therefore, more elements of your design might be visible. Because the protected model uses derived artifacts from a compiled model reference, you cannot change the model after you protect it.

Coordinate Settings with the User of Your Protected Model

When you develop a model that you will protect, coordinate with the user of the protected model to choose settings that allow their system to reference your protected model. After you protect your model, you cannot modify options such as configuration parameter settings to make your protected model compatible with a parent model. Before you protect your model, configure it to use compatible options.

Choose a Unique Model Name

You cannot change the name of your protected model after you protect it. To avoid name conflicts, choose a model name that is unique from other models in the system. Choose a model name that does not conflict with other models within your user's model hierarchy. Use the name to save your source (unprotected) model before you protect it.

Configure Model Parameters

Before you protect your model, choose configuration parameter settings by coordinating with the user of your protected model. When the parent model references your protected model, the configuration parameters of the models must be compatible, as described in Set Configuration Parameters for Model Hierarchies and Set Configuration Parameters for Code Generation of Model Hierarchies. For example, if you set the parameter Solver to Variable-step for your protected model, the model that references your protected model must have Solver set to Variable-step. If your model contains multiple configuration sets, the protected model uses the configuration set that is active when you protect the model. To minimize parameter incompatibilities, send your model configuration set to the user of your protected model so that they can use the configuration for their parent model. For more information, see Share a Configuration with Multiple Models.

Minimize the Model External Interface

Except for input and output ports, minimize the number of design elements that provide an interface into your model. To allow interfacing with external components, the protected model does not protect those design elements. For the following items, consider these alternative options that allow protection.

Tunable Parameters — Minimize the number of tunable parameters in the code that use a storage class other than Auto or Localizable. Parameters that use a global storage class in your model's generated code are visible in the code for the protected model. If the user of your protected model requires access to tunable parameters, agree on a list of the parameters that the protected model provides. For more information, see C Data Code Interface Configuration for Model Interface Elements.
Data Objects — Data objects, including parameter and signal data objects, data type objects, and bus objects, that you store externally are not protected. Include only data objects that the user of the protected model requires access to. Use the data objects to monitor signals and calibrate parameters while you develop your model. After calibration, specify values for the parameters, and then inline them. For more information, see Data Objects.
Data Stores — Do not use global data stores on signal objects. Global data stores can make data visible across referenced models. Instead, use inports and outports to communicate data across model references. You can use Data Store Memory blocks as data stores that are local to your model. For more information, see Local and Global Data Stores.
Model Arguments — Minimize the number of arguments that your model uses. When your protected model uses arguments, the user of your protected model must specify values for the arguments in the parent model. These data items are visible to the user of your protected model. For each model argument that your model uses, communicate the argument specifications to the user of your protected model.
Simulink Functions — Consider the scope of Simulink functions that your model uses. When a Simulink function has a global scope or is scoped at the root level of your model, it provides a visible interface with your protected model. If you do not want a Simulink function to interface into your protected model, consider specifying a scope within a subsystem of your model. For more information, see Scoped Simulink Function Blocks in Subsystems.
Logging Blocks — Do not use block-based logging in your protected model. To File blocks and To Workspace blocks that use the Timeseries format function in protected models, and therefore make the logged data visible to the protected model user. Signal logging, and other options that use the signal selector, do not work for signals inside a protected model.
Noninlined S-functions — Consider the content of noninlined S-functions that your model uses. When you protect a model that contains a noninlined S-function, the MEX files that you write for the S-function are placed in the protected model build folder and are visible to the user of your protected model.

Design Options in Your Protected Model

If you want to use one of the preceding design elements while you develop your model, but the element is not required by the user of the model, you can use variants to exclude the design element from your protected model. An example is using a To File block during testing to log data that the user of the protected model does not require access to. To exclude the block by using variants:

Insert a variant block, such as a Manual Variant Sink block, on the signal that leads to the To File block.
Connect the first output of the variant block to the To File block.
Connect the second output of the variant block to a Terminator block to terminate the signal.
To log the signal while testing the model, activate the first variant output.
To protect the model without using the logging block, activate the second variant output. The protected model uses only the active variant, so the signal is terminated without being logged.

Contents to Include in Your Protected Model

Model Protection Options

When you specify functionalities for your protected model, the protected model includes artifacts to support those functionalities. Limiting the included artifacts enables you to control what contents are visible to the user of your model or to an external attacker that wants to view or change your model without permission. Consider the trade-offs of different design options. To support additional functionalities, the protected model must include more content and therefore, more elements of your design might be visible. Coordinate with the user of your model to agree on what functionalities they require. Specify support for only those functionalities.

Obfuscated source code — Use this option when the user of your protected model must compile the generated source code. The protected model includes an obfuscated version of the generated source code. It behaves the same as your source code but is more difficult to understand for the model user and potential attackers.
Compiled code — Use this option when the user of your protected model can use the compiled library from your protected model. The protected model includes the binary files and header files compiled from your generated source code. It does not include the source code. This option prevents the user of your model and potential attackers from accessing the model's generated source code.
Password protection — Use this option to support some functionality for your protected model's user and protect the supporting files from external attackers. For each option that you specify a password, the derived files that support that option are protected by using AES-256 encryption. Before executing each functionality, the protected model prompts the user for a password. Coordinate with the user of your protected model to choose the password for each option. If your protected model is referenced by a parent model that will also be protected, do not password-protect functionalities that the parent protected model will support.
Digital signature — Sign your protected model by using a certificate to protect the recipient from using the model if it has been changed by an external attacker. When you sign your model, the user of the model can verify that the protected model is published by you and did not change after you signed it. After you sign the model, if it is changed, a user cannot use it. Make sure that the user's computer storage of trusted certificates has the certificate from the certificate authority that certified your certificate.

Interface Report

When you create a protected model, the generated protected model report includes an interface report. The interface report includes information about input and output specifications, exported functions, interface parameters, and data stores. Use the interface report as a reference to communicate with the user of your protected model.

Create a Harness Model

When you create a protected model, you have the option to create a harness model that references your protected model. Use the harness model to define information that the user requires to interface your protected model with their system. The harness contains the same configuration set that your protected model uses. In the harness model, you can include data definitions that your protected model uses.