Analyze Model Dependencies

What Are Model Dependencies?

Each Simulink^® model requires a set of files to run successfully. These files can include referenced models, data files, S-functions, subsystems, and other files the model cannot run without. These required files are called model dependencies.

Dependency Analysis Requirements	Tools to Choose
Find required files for an entire project.	Use dependency analysis from the Project. See Dependency Analysis.
Perform dependency analysis of a specific model with control of more options.	Use the manifest tools from your model. See Generate Manifests. Generate a manifest if you want to: Analyze a model that is not in a project. Save the list of the model dependencies to a manifest file. Create a report to identify where dependencies arise. Control the scope of dependency analysis.

Dependency Analysis Requirements

Tools to Choose

Find required files for an entire project.

Use dependency analysis from the Project. See Dependency Analysis.

Perform dependency analysis of a specific model with control of more options.

Use the manifest tools from your model. See Generate Manifests.

Generate a manifest if you want to:

Analyze a model that is not in a project.
Save the list of the model dependencies to a manifest file.
Create a report to identify where dependencies arise.
Control the scope of dependency analysis.

After you generate a manifest for a model to determine its dependencies, you can:

View the files required by your model in a manifest file.
Trace dependencies using the report to understand why a particular file or toolbox is required by a model.
Package the model with its required files into a zip file to send to another Simulink user.
Compare older and newer manifests for the same model.
Save a specific version of the model and its required files in a revision control system.

You can also view the libraries and models referenced by your model in a graphical format using the Model Dependency Viewer. See Model Dependency Viewer.

Generate Manifests

Generating a manifest performs the dependency analysis and saves the list of model dependencies to a manifest file. You must generate the manifest before using any of the other Simulink Manifest Tools.

Note

The model dependencies identified in a manifest depend upon the Analysis Scope options you specify. For example, performing an analysis without selecting Find Library Links might not find all the Simulink blocksets that your model requires, because they are often included in a model as library links. See Manifest Analysis Scope Options.

To generate a manifest:

On the Modeling tab, select Compare > Manifest > Generate Manifest.
The Generate Model Manifest dialog box appears.
Click OK to generate a manifest and report using the default settings.
Alternatively you can first change the following settings:
- Select the Analysis scope check boxes to specify the type of dependencies you want to detect (see Manifest Analysis Scope Options).
- Control whether to report file dependency locations by selecting Report file dependency locations for:
  - User files only (default) — only report locations where dependencies are upon user files. Use this option if you want to understand the interdependencies of your own code and do not care about the locations of dependencies on MathWorks^® products. This option speeds up report creation and streamlines the report.
  - All files — report all locations where dependencies are introduced, including all dependencies on MathWorks products. This is the slowest option and the most verbose report. Use this option if you need to trace all dependencies to understand why a particular file or toolbox is required by a model. If you need to analyze many references, it can be helpful to sort the results by clicking the report column headers.
  - None — do not report any dependency locations. This is the fastest option and the most streamlined report. Use this option if you want to discover and package required files and do not require all the information about file references.
- If desired, change the Project Root Location. If the model is in a project, you can select Current project root folder. Other check box options are: Folder containing root model file (the default), Common root folder of required files, or User-defined location — for this option, enter a path in the edit box, or browse to a location.
- If desired, edit the Manifest file name and location in which to save the file.
- Use the check box View HTML report on completion to specify if you want to generate a report when you generate the manifest. You can edit the Report file name or leave the default, mymodelname_manifest_report.html. You can set the Report style to Plain HTML or HTML with Hyperlinks.

When you click OK Simulink generates a manifest file containing a list of the model dependencies. If you selected View HTML report on completion, the Model Manifest Report appears after Simulink generates the manifest. See Use the Model Manifest Report for an example.

The manifest is an XML file with the extension .smf located (by default) in the same folder as the model itself.

Manifest Analysis Scope Options

The Simulink Manifest Tools allow you to specify the scope of analysis when generating the manifest. The dependencies identified by the analysis depend upon the scope you specify.

Tip

You can select analysis options that perform a Model Update. If Model Update fails you see an error message. Either clear those analysis options to generate a manifest without a Model Update, or try a manual Model Update to find out more about the problem. For example your model might require variables that are not present in the workspace (for example, if a block parameter defines a variable that you forgot to load manually).

The following table describes the Analysis Scope options.

Check Box Option	Description
Find orphaned base workspace data (performs a Model Update)	Searches for base workspace variables the model requires, that are not defined in any file in this Manifest.
Find enumeration definition files (performs a Model Update)	Searches for enumeration definition files. Turn on this option to detect enumerated data types used as part of a bus object definition.
Find and analyze model references	Searches for Model blocks in the model, and identifies any referenced models as dependencies.
Find and analyze subsystem references	Searches for subsystem blocks in the model, and identifies any referenced subsystems as dependencies.
Find and analyze linked libraries	Searches for links to library blocks in the model, and identifies any library links as dependencies.
Allow models with unsaved changes to be analyzed	Select this check box only if you want to allow analysis of unsaved changes.
Find requirements documents	Searches for requirements documents linked using the Requirements Management Interface. Note that requirements links created with IBM^® Rational^® DOORS^® software are not included in manifests. For more information, see Find Requirements Documents in a Project.
Click the >> button on the right to show the following advanced analysis options.
Find S-functions	Searches for S-Function blocks in the model, and identifies S-function files (MATLAB^® code and C) as dependencies. See the source code item in Special Cases.
Analyze model and block callbacks (including Interpreted MATLAB Function blocks)	Searches for file dependencies introduced by the code in Interpreted MATLAB Function blocks, block callbacks, and model callbacks. For more detail on how callbacks are analyzed, see Code Analysis.
Find files required for code generation	Searches for file dependencies introduced by Simulink Coder™ custom code, and Embedded Coder^® templates. If you do not have a code generation product, this check is off by default, and produces a warning if you select it. This includes analysis of all configuration sets (not just the Active set) and `STF_make_rtw_hook` functions, and locates system target files and Code Replacement Library definition files (.m or .mat). See also Required Toolboxes, and the source code item in Special Cases.
Find data files (e.g. in “From File” blocks)	Searches for explicitly referenced data files, such as those in From File blocks, and identifies those files as dependencies. See Special Cases.
Analyze Stateflow charts	Searches for file dependencies introduced by using syntax such as `ml.mymean(myvariable)` in models that use Stateflow^®.
Analyze code in MATLAB Functions blocks	Searches for MATLAB Function blocks in the model, and identifies any file dependencies (outside toolboxes) introduced in the code. Toolbox dependencies introduced by a MATLAB Function block are not detected.
Analyze files in “user toolboxes”	Searches for file dependencies introduced by files in user-defined toolboxes. See Special Cases.
Analyze MATLAB files	Searches for file dependencies introduced by MATLAB files called from the model. For example, if this option is selected and you have a callback to `mycallback.m`, then the referenced file `mycallback.m` is also analyzed for further dependencies. See Code Analysis.
Store MATLAB code analysis warnings in manifest	Saves any warnings in the manifest.

See also Scope of Dependency Analysis for more information.

Check File Dependencies

To programmatically check for file dependencies, use the function dependencies.fileDependencyAnalysis as follows.

[files, missing, depfile, manifestfile] = 
dependencies.fileDependencyAnalysis('modelname', 'manifestfile')

This returns the following:

files — a cell array of character vectors containing the full-paths of all existing files referenced by the model modelname.
missing — a cell array of character vectors containing the names all files that are referenced by the model modelname, but cannot be found.
depfile — returns the full path of the user dependencies (.smd) file, if it exists, that stores the names of any files you manually added or excluded. Simulink uses the .smd file to remember your changes the next time you generate a manifest. See Edit Manifests.
manifestfile — (optional input) specify the name of the manifest file to create. The suffix .smf is always added to the user-specified name.
If you specify the optional input, manifestfile, then the command creates a manifest file with the specified name and path manifestfile. manifestfile can be a full-path or just a file name (in which case the file is created in the current folder).

If you try this analysis on an example model, it returns an empty list of required files because the standard MathWorks installation includes all the files required for the example models.

Check Toolbox Dependencies

To check which toolboxes are required, use the function dependencies.toolboxDependencyAnalysis as follows:

[names,dirs] = dependencies.toolboxDependencyAnalysis(files_in)

files_in must be a cell array of character vectors containing .m or model files on the MATLAB path. Simulink model names (without file extension) are also allowed.

This returns the following:

names — a cell-array of toolbox names required by the files in files_in.
dirs — a cell-array of the toolbox folders.

Note

The method toolboxDependencyAnalysis looks for toolbox dependencies of the files in files_in but does not analyze any subsequent dependencies.

If you want to find all detectable toolbox dependencies of your model and the files it depends on:

Call fileDependencyAnalysis on your model.

For example:

[files, missing, depfile, manifestfile] = dependencies.fileDependencyAnalysis('mymodel')

files = 
    'C:\Work\manifest\foo.m'
    'C:\Work\manifest\mymodel'
missing =
     []
depfile =
     []
manifestfile =
     []

Call toolboxDependencyAnalysis on the files output of step 1.

For example:

tbxes = dependencies.toolboxDependencyAnalysis(files)

tbxes = 
[1x24 char]    'MATLAB'    'Simulink Coder'    'Simulink'

To view long product names examine the tbxes cell array as follows:

tbxes{:}

ans =
Image Processing Toolbox

ans =
MATLAB

ans =
Simulink Coder

ans =

Simulink

For command-line dependency analysis, the analysis uses the default settings for analysis scope to determine required toolboxes. For example, if you have code generation products, then the check Find files required for code generation is on by default and Simulink Coder is always reported as required. See Required Toolboxes for more examples of how your installed products and analysis scope settings can affect reported toolbox requirements.

Edit Manifests

After you generate a manifest, you can view the list of files identified as dependencies, and manually add or delete files from the list.

To edit the list of required files in a manifest:

On the Modeling tab, select Compare > Manifest > Edit Manifest.
Alternatively, if you are viewing a manifest report you can click Edit in the top Actions box, or you can click View and Edit Manifest in the Export Manifest dialog box.
The View and Edit Manifest dialog box appears, showing the latest manifest for the current model.

Note
You can open a different manifest by clicking the Browse for manifest file button . If you have not generated a manifest, select Generate Manifest to open the Generate Model Manifest dialog box (see Generate Manifests).
Examine the Files to be exported list on the left side of the dialog box. This list shows the files identified as dependencies.
To add a file to the manifest:
1. Click Add Files.
  The Add Files to Manifest dialog box opens.
2. Select the file you want to add, then click Open.
  The selected file is added to the Files to be exported list.
To remove a file from the manifest:
1. Select the file you want to remove from the Files to be exported list.
2. Click the Exclude selected files button .
  The selected file is moved to the Excluded files list.
  
  Note
  If you add a file to the manifest and then exclude it, that file is removed from the dialog box (it is not added to the Excluded files list). Only files detected by the Simulink Manifest Tools are included in the Excluded files list.
If desired, change the Project Root Location.
Click Save to save your changes to the manifest file.
Simulink saves the manifest (.smf) file, and creates a user dependencies (.smd) file that stores the names of any files you manually added or excluded. Simulink uses the .smd file to remember your changes the next time you generate a manifest, so you do not need to repeat manual editing. For example, you might want to exclude source code or include a copyright document every time you generate a manifest for exporting to a customer. The user dependencies (.smd) file has the same name and folder as the model. By default, the user dependencies (.smd) file is also included in the manifest.

Note
If the user dependencies (.smd) file is read-only, a warning is displayed when you save the manifest.
To view the Model Manifest Report for the updated manifest, click Show Report.
An updated Model Manifest Report appears, listing the required files and toolboxes, and details of references to other files. See Use the Model Manifest Report for an example.
When you are finished editing the manifest, click OK.

Compare Manifests

You can compare two manifests to see how the list of model dependencies differs between two models, or between two versions of the same model. You can also compare a manifest with a folder or a ZIP file.

To compare manifests:

From the Current Folder browser, right-click a manifest file and select Compare Against > Choose.
Alternatively, from your model, on the Modeling tab, select Compare > Manifest > Compare Manifests.
The dialog box Select Files or Folders for Comparison appears.
In the dialog box Select Files or Folders for Comparison, select files to compare, and the comparison type.
1. Use the drop-down lists or browse to select manifest files to compare.
2. Select the Comparison type. For two manifests you can select:
  - Simulink manifest comparison — Select for a manifest file list comparison reporting new, removed, and changed files. The report contains links to open files and compare files that differ. You can use a similar file List comparison for comparing a manifest to a folder or a ZIP file.
  - Simulink manifest comparison (printable) — Select for a printable Model Manifest Differences Report without links. The report provides details about each manifest file, and lists the differences between the files.
View the report in the Comparison Tool comparing the file names, dates, and sizes stored in the manifests.
Be aware the details stored in the manifest might differ from the files on disc. If you click a “compare” link in the report, you see warnings if there are problems such as size mismatches, or if the tool cannot find those files on disc.
For more information on the Comparison Tool, see Compare Files and Folders and Merge Files (MATLAB) in the MATLAB Data and File Management documentation.

Export Files in a Manifest

You can export copies of the files listed in the manifest to a ZIP file. Exporting the files allows you to package the model with its required files into a single ZIP file, so you can easily send it to another user or save it in a revision control system.

To export your model with its required files:

On the Modeling tab, select Compare > Manifest > Export Files in Manifest.
Alternatively, if you are viewing a manifest report you can click Export in the top Actions box.
The Export Files in Manifest dialog box appears, showing the latest manifest for the current model.

Note
You can export a different manifest by clicking the Browse for manifest file button . If you have not generated a manifest, select Generate Manifest to open the Generate Model Manifest dialog box (see Generate Manifests).
If you want to view or edit the manifest before exporting it, click View and Edit Manifest to view or change the list of required files. See Edit Manifests. When you close the View and Edit Manifest dialog box, you return to the Export Files in Manifest dialog box.
Click Validate to check the manifest. Validation reports information about possible problems such as missing files, warnings, and orphaned base workspace data.
Enter the ZIP file name to which you want to export the model.
Select Preserve folder hierarchy when exporting if you want to keep folder structure for your exported model and files. Then, select the root folder to use for this structure (usually the same as the Project Root Location on the Generate Manifest dialog box).

Note
You must select Preserve folder hierarchy if you are exporting a model that uses an .m file inside a MATLAB class (to maintain the folder structure of the class), or if the model refers to files in other folders (to ensure the exported files maintain the same relative paths).
Click OK.
The model and its file dependencies are exported to the specified ZIP file.

Scope of Dependency Analysis

The Simulink Manifest Tools identify required files and list them in an XML file called a manifest. When Simulink generates a manifest file, it performs a static analysis on your model, which means that the model does not need to be capable of performing an “update diagram” operation (see Update Diagram and Run Simulation). The only exception to this is when you select the analysis option Find orphaned base workspace data (performs a Model Update).

You can specify the type of dependencies you want to detect when you generate the manifest. See Manifest Analysis Scope Options.

For more information on what the tool analyzes, refer to the following sections:

Analysis Limitations
Code Analysis
Special Cases

Analysis Limitations

The analysis might not find all files required by your model (for examples, see Code Analysis).

The analysis might not report certain blocksets or toolboxes required by a model. You should be aware of this limitation when sending a model to another user. Blocksets that do not introduce dependence on any files (such as Fixed-Point Designer™) cannot be detected. Some SimEvents^® blocks do not introduce a detectable dependence on SimEvents.

To include dependencies that the analysis cannot detect, you can add additional file dependencies to a manifest file using the View/Edit Manifest Contents option (see Edit Manifests).

Code Analysis

When the Simulink dependency analysis encounters MATLAB code, for example in a model or block callback, or in a .m file S-function, the analysis attempts to identify the files it references. If those files contain MATLAB code, and the analysis scope option Analyze MATLAB files is selected, the referenced files are also analyzed. This function is similar to matlab.codetools.requiredFilesAndProducts but with some enhancements:

Character vectors passed into calls to eval, evalc, and evalin are analyzed.
File names passed to load, fopen, xlsread, importdata, dlmread, and imread are identified.

Files that are in MathWorks toolboxes are not analyzed.

File names passed to load, etc., are identified only if they are literal character vectors, for example:

load('mydatafile')
load mydatafile

If you define a file name as a variable and pass that to a function, the file is a hidden dependency. The following example, and anything more complicated, does not identify the dependency because the file name is inside a variable:

str = 'mydatafile';
load(str);

Similarly, arguments to eval, etc., are analyzed only if they are literal character vectors.

The Simulink dependency analysis looks inside MAT-files to find the names of variables to be loaded. This enables them to distinguish reliably between variable names and function names in block callbacks.

If a model depends upon a file for which both .m and .p files exist, then the manifest reports both, and, if the Analyze MATLAB files option is selected, the .m file is analyzed.

Special Cases

The following list contains more information about specific cases:

If your model references a data class created using MATLAB syntax, for example called MyPackage.MyClass, all files inside the folder MyPackage and its subfolders are added to the manifest.
Warning
The analysis adds all files in the class, which includes any source control files such as .svn or .cvs. You might want to edit the manifest to remove these files.
A user-defined toolbox must have a properly configured Contents.m file. The Simulink Manifest Tools search user-defined toolboxes as follows:
- If you have a Contents.m file in folder X, any file inside a subfolder of X is considered part of your toolbox.
- If you have a Contents.m file in folder X/X, any file inside all subfolders of the “outer” folder X is considered part of your toolbox.
  For more information on the format of a Contents.m file, see ver.
If your S-functions require TLC files, these are detected.
If you have Simscape™, your Simscape components are analyzed. See also Required Toolboxes for other effects of your installed products on manifests.
If you create a UI using GUIDE and add this to a model callback, then the dependency analysis detects the .m and .fig file dependencies.
If you have a dependence on source code, such as .c, .h files, these files are not analyzed at all to find any files that they depend upon. For example, subsequent #include calls inside .h files are not detected. To make such files detectable, you can add them as dependent files to the "header file" section of the Custom Code pane of the Simulink Coder section of the Configuration Parameters dialog box (or specify them with rtwmakecfg). Alternatively, to include dependencies that the analysis cannot detect, you can add additional file dependencies to a manifest file using the View/Edit Manifest Contents option (see Edit Manifests).

Various blocksets and toolboxes can introduce a dependence on a file through their additional source blocks. If the analysis scope option Find data files (e.g. in “From File” blocks) is selected, the analysis detects file dependencies introduced by the following blocks:

Product	Blocks
DSP System Toolbox™	From Wave File (Obsolete) block (Microsoft^® Windows^® operating system only) From Multimedia File block (Windows only)
Computer Vision Toolbox™	Image From File block Read Binary File block
Simulink 3D Animation™	VR Sink block

Product

Blocks

DSP System Toolbox™

From Wave File (Obsolete) block (Microsoft^® Windows^® operating system only)

From Multimedia File block (Windows only)

Computer Vision Toolbox™

Image From File block

Read Binary File block

Simulink 3D Animation™

VR Sink block

The option Find data files also detects dependencies introduced by setting a "Model Workspace" for a model to either MAT-File or MATLAB Code, and model dependencies specified on the Model Referencing pane of the Configuration Parameters dialog box.

Best Practices for Dependency Analysis

The starting point for dependency analysis is the model itself. Make sure that the model refers to any data files it needs, even if you would normally load these manually. For example, add code to the model's PreLoadFcn to load them automatically, like this example:

load mydatafile
load('my_other_data_file.mat')

This way, the Simulink Manifest Tools can add them to the manifest. For more detail on callback analysis, see the notes on code analysis (see Code Analysis).

More generally, ensure that the model creates or loads any variables it uses, either in model callbacks or in scripts called from model callbacks. This reduces the possibility of the Simulink Manifest Tools confusing variable names with function names when analyzing block callbacks.

If you plan to export the manifest after creating it, ensure that the model does not refer to any files by their absolute paths, for example:

load C:\mymodel\mydata\mydatafile.mat

Absolute paths can become invalid when you export the model to another machine. If referring to files in other folders, do it by relative path, for example:

load mydata\mydatafile.mat

Select Preserve folder hierarchy when exporting, so that the exported files are in the same locations relative to each other. Also, choose a root folder so that all the files listed in the manifest are inside it. Otherwise, any files outside the root are copied into a new folder called external underneath the root, and relative paths to those files become invalid.

If you are exporting a model that uses a .m file inside a MATLAB class (in a folder called @myclass, for example), you must select the Preserve folder hierarchy check box when exporting, to maintain the folder structure of the class.

Always test exported ZIP files by extracting the contents to a new location on your computer and testing the model. Be aware that in some cases required files might be on your path but not in the ZIP file, if your path contains references to folders other than MathWorks toolboxes.

Use the Model Manifest Report

Report Sections
Required Toolboxes
Example Model Manifest Report

Report Sections

If you selected View HTML report on completion in the Generate Model Manifest dialog box, the Model Manifest Report appears after Simulink generates the manifest. The report shows:

Analysis date
Actions pane — Provides links to regenerate, edit, or compare the manifest, and export the files in the manifest to a ZIP file.
Model Reference and Library Link Hierarchy — Links you can click to open models.
Files used by this model — Required files, with paths relative to the projectroot.
You can sort the results by clicking the report column headers.
Toolboxes required by this model. For details, see Required Toolboxes.
References in this model — This section provides details of references to other files so you can identify where dependencies arise. You control the scope of this section with the Report file dependency locations options on the Generate Manifest dialog box. You can choose to include references to user files only, all files, or no files. See Generate Manifests. Use this section of the report to trace dependencies to understand why a particular file or toolbox is required by a model. If you need to analyze many references, it can be helpful to sort the results by clicking the report column headers.
Folders referenced by this model
Orphaned base workspace variables — If you selected the analysis option Find orphaned base workspace data, this section reports any base workspace variables the model requires that are not defined in a file in this manifest.
Warnings generated while analyzing MATLAB code — You can opt out of this section by clearing the Store MATLAB code analysis warnings in manifest analysis option.
Dependency analysis settings — Records the details of the analysis scope options.

See the examples shown in Example Model Manifest Report.

Required Toolboxes

In the report, the “Toolboxes required by this model” section lists all products required by the model that the analysis can detect. Be aware that the analysis might not report certain blocksets or toolboxes required by a model, e.g., blocksets that do not introduce dependence on any files (such as Fixed-Point Designer) cannot be detected. Some MathWorks files under toolbox/shared can report only requiring MATLAB instead of their associated toolbox.

The results reported can be affected by your analysis scope settings and your installed products. For example:

If you have code generation products and select the scope option “Find files required for code generation”, then:
- Simulink Coder software is always reported as required.
- If you also have an .ert system target file selected, then Embedded Coder software is always reported as required.
If you clear the Find library links option, then the analysis cannot find a dependence on, for example, someBlockSet, and so no dependence is reported upon the block set.
If you clear the Analyze MATLAB files option, then the analysis cannot find a dependence upon fuzzy.m, and so no dependence is reported upon the Fuzzy Logic Toolbox™.

Example Model Manifest Report

You should always check the Dependency analysis settings section in the Model Manifest Report to see the scope of analysis settings used to generate it.

Following are portions of a sample report.