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 Using the 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. Select the Analysis scope check boxes to specify the type of dependencies you want to detect (see Manifest Analysis Scope Options).

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

4. If desired, change the Project Root Location. Select one of the check box options:

   • Directory containing root model file (the default).

   • Common root folder of required files.

   • User-defined location — for this option, enter a path in the edit box, or browse to a location.

5. Specify the Manifest file name and location in which to save the file.

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

7. 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 directory 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') 

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.

• manifestfile — (optional) 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 manifestfile. manifestfile can be a full-path or just a file name (in which case the file is created in the current directory).

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

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'    'Real-Time Workshop'    'Simulink'
   

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

   tbxes{:}
   
   ans =
   Image Processing Toolbox
   
   ans =
   MATLAB
   
   ans =
   Real-Time Workshop
   
   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 Real-Time Workshop 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.

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

   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.

To compare manifest files:

1. Select Tools > Model Dependencies > Compare Manifests.

   The Compare Manifests dialog box appears.

   

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

3. Select the older manifest file.

4. Specify a report file name and location.

   Note   The default report file is manifest_comparison_report.html in the current working directory.

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

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.

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

3. 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 (usually the same as the Project Root Directory on the Generate Manifest dialog box).

   Note   You must select Preserve directory hierarchy if you are exporting a model that uses an M-file inside a MATLAB class (to maintain the directory structure of the class), or if the model refers to files in other directories (to ensure the exported files maintain the same relative paths).

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

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

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

• M-Code Analysis

• Special Cases

Analysis Limitations

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

M-Code Analysis

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 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-file and P-file exist, then the manifest reports both, and, if the Analyze M-files option is selected, the M-file is analyzed.

Special Cases

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.

• 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 Real-Time Workshop 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
  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
  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 M-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 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.

Back to Top

Using the Model Manifest Report

• Required Toolboxes

• Example Model Manifest Report

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

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

• Directories referenced by this model.

• Dependency analysis settings — records the details of the analysis scope options.

• Actions — Provides links to conveniently regenerate, edit or compare the manifest, and export the files in the manifest to a zip file.

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.

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:

  • Real-Time Workshop software is always reported as required.

  • If you also have an .ert system target file selected then Real-Time Workshop Embedded Coder software is always reported as required.

  • If your model uses Stateflow software, then Stateflow^® Coder™ 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 M-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 is a portion of an sample report.

Back to Top

Using the Model Dependency Viewer

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:

• About Model Dependency Views

• Opening the Model Dependency Viewer

• Manipulating a Dependency View

• Browsing Dependencies

• Saving a Dependency View

• Printing a Dependency View

About Model Dependency Views

The Model Dependency Viewer allows you to choose between the following types of dependency views of a model reference hierarchy.

• File Dependency View

• Referenced Model Instances View

• Processor-in-the-Loop Mode Indicator

• Error and Warning Icons

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.

Boxes representing protected referenced models models have a lock icon, and the model name has the .mdlp extension. Protected referenced model boxes have no expand(+)/collapse(–) button.

Processor-in-the-Loop Mode Indicator.   An instance view appends PIL to the names of models that run in Processor-in-the-Loop mode (see Specifying the Simulation Mode). For example, the following dependency instance view indicates that the model named rtwdemo_pil_component runs in processor-in-the-loop mode.

Error and Warning Icons.   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.

Opening the Model Dependency Viewer

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:

1. Open the model.

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

Manipulating a Dependency View

The Model Dependency Viewer allows you to manipulate dependency views in various ways. See the following topics for more information:

• Changing Dependency View Type

• Excluding Block Libraries from a File Dependency View

• Including Simulink Blocksets in a File Dependency View

• Changing View Orientation

• Expanding or Collapsing Views

• Zooming a Dependency View

• Moving a Dependency View

• Rearranging a Dependency View

• Displaying and Hiding a Dependency View's Legend

• Displaying Full Paths of Referenced Model Instances

• Refreshing a Dependency View

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:

1. Move the cursor over the view.

2. Press your keyboard's space bar and your mouse's left button simultaneously.

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

1. Select the block you want to move by clicking it.

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

Browsing Dependencies

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.

Saving a Dependency View

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.

Printing a Dependency View

To print a dependency view:

• Select File > Print from the dependency viewer's menu bar.

Back to Top

The Model Browser

Managing Configuration Sets

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