| Simulink® | |
| On this page… |
|---|
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 Using the Model Dependency Viewer.
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).
You can specify the type of dependencies you want to detect when you generate the manifest. For more information on what the tool analyzes, refer to the following sections:
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.
| Check Box Option | Description |
|---|---|
| Find model references | Searches for Model blocks in the model, and identifies any referenced models as dependencies. |
| Find library links | Searches for links to library blocks in the model, and identifies any library links as dependencies. |
Find S-functions | Searches for S-Function blocks in the model, and identifies S-function files (M-code and C) as dependencies. |
| Analyze model and block callbacks (including "MATLAB Fcn" blocks) | Searches for file dependencies introduced by the M-code in MATLAB Fcn blocks, block callbacks, and model callbacks. For more detail on how callbacks are analyzed, see M-Code Analysis. |
| Find files required for code generation | Searches for file dependencies introduced by Real-Time Workshop® custom code, and Real-Time Workshop® Embedded Coder™ templates. |
| 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 through the use of syntax such as ml.mymean(myvariable) in models that use Stateflow®. |
| Analyze code in Embedded MATLAB blocks | Searches for Embedded MATLAB Function blocks in the model, and identifies any file dependencies (outside toolboxes) introduced in the M-code. Toolbox dependencies introduced by an Embedded MATLAB™ Function block are not detected. |
| Find requirements documents | Searches for requirements documents linked using the Requirements Management Interface. For more information, see Managing Model Requirements in the Simulink® Verification and Validation™ User's Guide. |
| Analyze files in "user toolboxes" | Searches for file dependencies introduced by files in user-defined toolboxes. See Special Cases. |
| Analyze M-files | Searches for file dependencies introduced by M-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 M-Code Analysis. |
The analysis might not find all files required by your model (for examples, see M-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).
When the Simulink Manifest Tools encounter M-code, for example in a model or block callback, or in an M-file S-function, they attempt to identify the files it references. If those files contain M-code, and the analysis scope option Analyze M-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, csvread, wk1read, textread and imread are identified.
File names passed to load, etc., are identified only if they are literal strings. For example:
load('mydatafile')
load mydatafileThe 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.
The following list contains additional information about specific cases:
If your model uses classes created using the Data Class Designer and references a class called MyPackage.MyClass, all files inside the directory @MyPackage and its subdirectories are added to the manifest.
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 directory X, any file inside a sub-directory of X is considered part of your toolbox.
If you have a Contents.m file in directory X/X, any file inside all sub-directories of the "outer" directory 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 create a UI using GUIDE and add this to a model callback, then the dependency analysis detects the M-file and .fig file dependencies.
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 |
|---|---|
| Signal Processing Blockset™ | From Wave File block (Microsoft® Windows® operating system only) From Multimedia File block (Windows only) |
| Video and Image Processing Blockset™ | Image From File block Read Binary File block |
| Virtual Reality Toolbox™ | 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 M-Code.
To programmatically check for file dependencies, use the method dependencies.fileDependencyAnalysis as follows.
[files, missing, depfile] = dependencies.fileDependencyAnalysis('modelname') 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 — the full-path of the file containing information about any user-defined files associated with the model modelname.
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.
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 M-code analysis (see M-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 directories, do it by relative path, for example:
load mydata\mydatafile.mat
Select Preserve directory hierarchy when exporting, so that the exported files are in the same locations relative to each other. Also, choose a root directory so that all the files listed in the manifest are inside it. Otherwise, any files outside the root are copied into a new directory called external underneath the root, and relative paths to those files become invalid.
If you are exporting a model that uses an M-file inside a MATLAB® class (in a directory called @myclass, for example), you must select the Preserve directory hierarchy check box when exporting, to maintain the directory 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 directories other than MathWorks toolboxes.
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. You should always look at the Dependency analysis settings: section at the top of the Model Manifest Report to see the scope of analysis used to generate it. For more information, see Viewing the Model Manifest Report. |
To generate a manifest:
Select Tools > Model Dependencies > Generate Manifest.
The Generate Model Manifest dialog box appears.
Select the Analysis scope check boxes to specify the type of dependencies you want to detect (see Analysis Options).
Specify the Manifest file name and location in which to save the file.
To generate a report when you generate the manifest, select View HTML report on completion, then specify the Report style (Plain HTML or HTML with Hyperlinks) and Report file name.
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. The report shows details of the analysis scope under the heading Dependency analysis settings, lists the required files and toolboxes, and provides details of references to other files so you can identify where dependencies arise.
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:
Select Tools > Model Dependencies > View/Edit Manifest Contents.
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
|
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.
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 added manually, as well as those you manually excluded. Simulink uses the .smd file to remember your changes the next time you generate a manifest. The user dependencies (.smd) file has the same name and directory as the model. By default, the user dependencies (.smd) file is also included in 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 Viewing 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.
To compare manifest files:
Select Tools > Model Dependencies > Compare Manifests.
The Compare Manifests dialog box appears.
Select the newer manifest file.
Note You can click Generate Manifest to create a new manifest. See Generating Manifests for more information. After you generate the manifest, you return to the Compare Manifests dialog box. |
Select the older manifest file.
Specify a report file name and location.
Click OK.
The two manifests are compared and displays the Model Manifest Differences Report. The report provides details about each manifest file, and lists the differences between the files.
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:
Select Tools > Model Dependencies > Export Files in Manifest.
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 want to view or edit the manifest before exporting it, select 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.
Select Preserve directory hierarchy if you want to keep directory structure for your exported model and files. Then, select the root directory to use for this structure.
Enter the zip file name to which you want to export the model.
Click OK.
The model and its file dependencies are exported to the specified zip file.
The Model Dependency Viewer displays a dependency view of a model. The dependency view is a graph of all the models and libraries referenced directly or indirectly by the model. You can use the dependency view to quickly find and open referenced libraries and models.
See the following topics for information on using the viewer:
The Model Dependency Viewer allows you to choose between the following types of dependency views of a model reference hierarchy.
File Dependency View. A file dependency view shows the model and library files referenced by a top model. A referenced model or library file appears only once in the view even if it is referenced more than once in the model hierarchy displayed in the view. A file dependency view consists of a set of blocks connected by arrows. Blue blocks represent model files; brown boxes, libraries. Arrows represent dependencies. For example, the arrows in the following view indicate that the aero_guidance model references two libraries: aerospace and simulink_need_slupdate.
An arrow that points to the library from which it emerges indicates that the library references itself, i.e., blocks in the library reference other blocks in that same library. For example, the preceding view indicates that the aerospace library references itself.
A file dependency view optionally includes a legend that identifies the model in the view and the date and time the view was created.
Referenced Model Instances View. A referenced model instances view shows every reference to a model in a model reference hierarchy (see Referencing a Model) rooted at the top model targeted by the view. If a model hierarchy references the same model more than once, the referenced model appears multiple times in the instance view, once for each reference. For example, the following view indicates that the model reference hierarchy rooted at sldemo_mdlref_depgraph contains two references to the model sldemo_mdlref_F2C.
In an instance view, boxes represent a top model and model references. Boxes representing accelerated-mode instances (see Referenced Model Simulation Modes) have filled triangles in their corners; boxes representing normal-mode instances, have unfilled triangles in their corners. For example, the following diagram indicates that one of the references to sldemo_mdlref_F2C operates in normal mode; the other, in accelerated mode.
An instance view displays warning or error icons on instance boxes to indicate invalid normal-mode references (see Mixing Simulation Modes).
| Icon | Indicates |
|---|---|
 | A reference configured to run in normal mode actually runs in accelerated mode because it is directly or indirectly referenced by another model reference that runs in accelerated mode. |
 | One of multiple normal-mode references to the same model in a model reference hierarchy. Such a reference is invalid because it violates the rule that only one normal-mode reference to a model can occur in a given model reference hierarchy. |
The following instance view, for example, indicates that the accelerated-mode configuration of the reference to sldemo_mdlref_heater overrides the normal-mode configurations of its reference to sldemo_mdlref_F2C.
Changing the simulation mode of the reference to sldemo_mdlref_heater to normal creates two normal-mode references in the model reference hierarchy to the same model, i.e., sldemo_mdlref_F2C, which is invalid as indicated in the following instances view.
The Model Dependency Viewer displays a graph of all the models and libraries referenced directly or indirectly by the model. You can use the dependency viewer to quickly find and open referenced libraries and models.
To display a dependency view for a model:
Open the model.
Select Tools > Model Dependencies > Model Dependency Viewer, then select the type of view you want to see:
.mdl File Dependencies Including Libraries
.mdl File Dependencies Excluding Libraries
Referenced Model Instances
The Model Dependency Viewer appears, displaying a dependency view of the model.
The Model Dependency Viewer allows you to manipulate dependency views in various ways. See the following topics for more information:
Changing Dependency View Type. You can change the type of dependency view displayed in the viewer.
To change the type of dependency view:
Select View > Dependency Type > .mdl File Dependencies (see File Dependency View )
or
Select View > Dependency Type > Referenced Model Instances (see Referenced Model Instances View ).
Excluding Block Libraries from a File Dependency View. By default a file dependency view includes libraries on which a model depends.
To exclude block libraries:
Deselect View > Include Libraries.
Including Simulink® Blocksets in a File Dependency View. By default, a file dependency view omits block libraries supplied by The MathWorks™ when View > Include Libraries is selected.
To include libraries supplied by The MathWorks:
Select View > Show MathWorks Dependencies.
Changing View Orientation. By default the orientation of the dependency graph displayed in the viewer is vertical.
To change the orientation to horizontal:
Select View > Orientation > Horizontal.
Expanding or Collapsing Views. You can expand or collapse each model or library in the dependency view to display or hide the dependencies for that model or library.
To expand or collapse views:
Click the expand(+)/collapse(-) button on the box representing the model or library to expand or collapse that view.
Zooming a Dependency View. You can enlarge or reduce the size of the dependency graph displayed in the viewer.
To zoom a dependency view in or out, do either of the following:
Press and hold down the spacebar key and then press the + or - key on the keyboard.
Move the scroll wheel on your mouse forward or backward.
To fit the view to the viewer window:
Press and release the spacebar key.
Moving a Dependency View. You can move a dependency view to another location in the viewer window.
To move the dependency view:
Move the cursor over the view.
Press your keyboard's space bar and your mouse's left button simultaneously.
Move the cursor to drag the view to another location.
Rearranging a Dependency View. You can rearrange a dependency view by moving the blocks representing models and libraries. This can make a complex view easier to read.
To move a block to another location:
Select the block you want to move by clicking it.
Drag and drop the block in the new location.
Displaying and Hiding a Dependency View's Legend. The dependency view can display a legend that identifies the model in the view and the date and time the view was created.
To display or hide a dependency view's legend:
Select View > Show Legend from the viewer's menu bar.
Displaying Full Paths of Referenced Model Instances. In an instance view (see Referenced Model Instances View) , you can display the full path of a model reference in a tooltip or in the box representing the reference.
To display the full path in a tooltip:
Move the cursor over the box representing the reference in the view.
A tooltip appears, displaying the path displays the full path of the Model block corresponding to the instance.
To display full paths in the boxes representing the instances:
Select View > Show Full Path.
Each box in the instance view now displays the path of the Model block corresponding to the instance. The name of the referenced model appears in parentheses as illustrated in the following figure.
Refreshing a Dependency View. After changing a model displayed in a dependency view or any of its dependencies, you must update the view to reflect any dependency changes.
To update the view:
Select View > Refresh from the dependency viewer's menu bar.
You can use a dependency view to browse a model's dependencies:
To open a model or library displayed in the view, double-click its block.
To display the Model block corresponding to an instance in an instance view, right-click the instance and select Highlight Block from the menu that appears.
To open all models displayed in the view, select File > Open All Models from the viewer's menu bar.
To save all models displayed in the view, select File > Save All Models.
To close all models displayed in the view, select File > Close All Models.
You can save a dependency view for later viewing.
To save the current view:
Select File > Save As from the viewer's menu bar, then enter a name for the view.
To reopen the view:
Select File > Open from any viewer's menu bar, then select the view you want to open.
To print a dependency view:
Select File > Print from the dependency viewer's menu bar.
| The Model Browser | Running Simulations | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
