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, and other files without which the model cannot run. These required files are called model dependencies.

The Simulink Manifest Tools allow you to analyze a model to determine its model dependencies. After you identify these dependencies, you can:

• View the files required by your model in a "manifest" file.

• 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.

Back to Top

Generating 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 you specify. For example, performing an analysis without selecting Find Library Links may not find all the Simulink Blocksets that your model requires, since these are often included in a model as library links. See Manifest Analysis Scope Options.

To generate a manifest:

1. Select Tools > Model Dependencies > Generate Manifest.

   The Generate Model Manifest dialog box appears.

   

2. 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. Select one of the check box options: 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 Using 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.

The following table describes the Analysis Scope options.

See also Scope of Dependency Analysis for more information.

Back to Top

Command-Line Dependency Analysis

• Check File Dependencies

• Check Toolbox Dependencies

Check File Dependencies

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

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

This returns the following:

• files — a cell array of strings containing the full-paths of all existing files referenced by the model modelname.

• missing — a cell array of strings 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 Editing Manifests.

• manifestfile — (optional input) specify the name of the manifest file to create. Note that 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 a demo model, it returns an empty list of required files because the standard MathWorks installation includes all the files required for the demo models.

Check Toolbox Dependencies

To check which toolboxes are required, enter:

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

files_in must be a cell array of strings containing .m or .mdl files on the MATLAB path. Simulink model names (without .mdl 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:

1. Call fileDependencyAnalysis on your model.

   For example:

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

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

2. 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.

Back to Top

Editing 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:

1. Select Tools > Model Dependencies > View/Edit Manifest Contents.

   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 Generating Manifests).

2. Examine the Files to be exported list on the left side of the dialog box. This list shows the files identified as dependencies.

3. 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.

4. 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 (it is not added to the Excluded files list). Only files detected by the Simulink Manifest Tools are included in the Excluded files list.

5. If desired, change the Project Root Location.

6. 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.

7. 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 Using the Model Manifest Report for an example.

8. When you are finished editing the manifest, click OK.

Back to Top

Comparing 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:

1. From the Current Folder browser, right-click a manifest file and select Compare Against > Choose.

   Alternatively, from your model, select Tools > Model Dependencies > Compare Manifests.

   The dialog box Select Files or Folders for Comparison appears.

2. 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.

3. 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 may differ from the files on disk. 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 disk.

   For more information on the Comparison Tool, see Comparing Files and Folders in the MATLAB Desktop Tools and Development Environment documentation.

Back to Top

Exporting 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:

1. Select Tools > Model Dependencies > 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 Generating Manifests).

2. 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 Editing Manifests. When you close the View and Edit Manifest dialog box, you return to the Export Files in Manifest dialog box.

3. Click Validate to check the manifest. Validation reports information about possible problems such as missing files, warnings, and orphaned base workspace data.

4. Enter the ZIP file name to which you want to export the model.

5. 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).

6. Click OK.

   The model and its file dependencies are exported to the specified ZIP file.

Back to Top

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 Updating a Block Diagram). 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 Simulink^® Fixed Point™) cannot be detected.

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 Editing Manifests).

Code Analysis

When the Simulink Manifest Tools encounter MATLAB code, for example in a model or block callback, or in a .m file S-function, they attempt 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 depfun but with some enhancements:

• Files that are in MathWorks toolboxes are not analyzed.

• Strings passed into calls to eval, evalc, and evalin are analyzed.

• File names passed to load, fopen, xlsread, importdata, dlmread, wk1read, and imread are identified.

File names passed to load, etc., are identified only if they are literal strings. For example:

load('mydatafile')
load mydatafile

The following example, and anything more complicated, is not identified as a file dependency:

str = 'mydatafile';
load(str);

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

The Simulink Manifest Tools look 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 additional information about specific cases:

• If your model references a user-defined MATLAB class created using the Data Class Designer, 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 may 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 will be 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 Editing 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 System 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.

Back to Top

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, e.g.,

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 may be on your path but not in the ZIP file, if your path contains references to folders other than MathWorks toolboxes.

Back to Top

Using 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 panel — Provides links to conveniently 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 Generating 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 Simulink Fixed Point) 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.mdl, 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.

Back to Top

Using Templates to Create Standard Project Settings

Simulating Dynamic Systems

Related Products & Applications

• Simulink
• Control Design
• Signal Processing & Communications
• Model-Based Design
• Physical Modeling
• Verification & Validation

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit