There are a few approaches one can follow, based on the level of protection required. Please note that we assume both parent and child models use GRT.tlc or ERT.tlc.
1. Protected Model
Create a protected model using one of the following options.
a. The Model block context menu. For more information, see Create a Protected Model
b. The Simulink.ModelReference.protect function.
You can optionally include generated code with the protected model so that a third party can generate code for a model that contains the protected model. Including code generation support with a protected model also allows the third party to simulate a model that references the protected model in Accelerator mode.
If you choose to obfuscate the code, the code is obfuscated before compilation. The protected model file contains only obfuscated headers and binaries. Source code, such as .c and .cpp, is not present in the protected model file, although the headers are documented in the protected model report.
For more information, see the following:
2. S-Function
One can generate an S-function from the child subsystem. To do this, open the model, and right click on the child subsystem. Select the option to generate an S-function target. This should convert the child subsystem into an S-function and also generate a block for this. Insert this new block in the parent model. Simulation should yeild identical results as when you had the child subsystem in the model. You can generate code from the parent as well. Please note that if you are using ERT.tlc, you may have to change some configuration parameters to enable code generation with non-inlined S-functions. For more information on creating S-function blocks from subsystems, please refer to the following documentation link.
The advantage of this method is that the block implementation of the child S-function is now hidden. The disadvantages are twofold: firstly, the algorithm is now exposed via C code in the S-function; secondly, there is a lot of execution overhead because the generated code calls the "mdlOutputs" function of the S-function.
3. Static Library
If you require a stronger level of protection, we suggest converting the algorithm contained within the subsystem into a static library, and ensure the generated code uses the static library instead of the subsystem blocks, or the S-function itself. Firstly, to improve the efficiency of the generated code, one would have to inline the generated S-function. This can be done by writing a TLC for the S-function.
i. Secondly, in order to hide the implementation of the child subsystem in the generated code, one has to convert the functional algorithm of the child subsystem into a static library. This can be done by creating a new project in a third party environment like Visual Studio etc, and build a static library.
ii. Once we have the static library, the next step is to ensure that the generated code picks up this static library instead of the C source. This is achieved with two steps:
a) Remove the source files from the include path. Do this by modifying the TLC for the chlild S-function;
b) Modify the make file for the parent model and inform the MAKE utility about the existence and full path of the generated static library.
One can modify the make file by one of the two ways
a) Add the full path to the generated library in the Configuration Parameters -> Code Generation -> Custom Code -> Include libraries section
b) Create a file called: rtwmakecfg.m within the folder that contains the parent model. Include the full path to the library in this file. The build process will modify the make file based on the rtwmakecfg.m if such a file exists.
The advantage with this process is that the child algorithm is now captured in a static library, which is a higher level of protection. The disadvantages of this process are the following:
a) It is a bit involved
b) It is not as convenient as using model references. With model references, you can reference a child model within a parent only if both configuration sets are compatible. There is no way to ensure this while using the above approach. This can have an effect when you change parameters like sample time in the configuration set of the parent.
Attachments:
1) model that contains the child subsystem
2) S-function generated from child subsystem
3) TLC file to inline the S-function
4) *.c and *.h file that is used within MSVC environment to generate static library
5) rtwmakecfg.m file that includes that full path to the generated library
6) parent model that calls the child subsystem using an S-function block.
