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:
|
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.
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.
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,
.
You can set the Report style to mymodelname
_manifest_report.htmlPlain
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.
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.
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 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.
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.
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.
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.
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.
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:
Click Add Files.
The Add Files to Manifest dialog box opens.
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:
Select the file you want to remove from the Files to be exported list.
Click the Exclude selected files button .
The selected file is moved to the Excluded files list.
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.
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.
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.
Use the drop-down lists or browse to select manifest files to compare.
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.
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.
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).
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.
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:
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).
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
str = 'mydatafile'; load(str);
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.
The following list contains more information about specific cases:
If your model references a data class created using MATLAB syntax,
for example called
,
all files inside the folder MyPackage.MyClass
and
its subfolders are added to the manifest.MyPackage
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 |
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.
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')
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
load mydata\mydatafile.mat
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.
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.
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,
,
and so no dependence is reported upon the block set.someBlockSet
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™.
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.