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.
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.
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.
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. For example, if you set the parameter Solver
Variable-step for your protected model, the model
that references your protected model must have Solver set
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.
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
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 Code Generation 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
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.
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.
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.
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.
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.