SIMULINK. Exploring - Searching and Browsing Models

SIMULINK
Exploring, Searching and Browsing Models
J. ABELL
Exploring, Searching, and Browsing Models
Model Explorer Overview

What You Can Do Using the Model Explorer Opening the Model Explorer
Model Explorer Components
The Main Toolbar
Adding Objects
Customizing the Model Explorer Interface Basic Steps for Using the Model Explorer Focusing on
Specific Elements of a Model or Chart
Model Explorer: Model Hierarchy Pane

What You Can Do with the Model Hierarchy Pane Simulink Root
Base Workspace
Configuration Preferences
Model Nodes
Displaying Partial or Whole Model Hierarchy Contents Displaying Linked Library Subsystems
Displaying Masked Subsystems
Linked Library and Masked Subsystems
Displaying Node Contents
Navigating to the Block Diagram
Working with Configuration Sets
Expanding Model References
Cutting, Copying, and Pasting Objects
Model Explorer: Contents Pane
Contents Pane Tabs

Data Displayed in the Contents Pane
Link to the Currently Selected Node
Horizontal Scrolling in the Object Property Table Working with the Contents Pane
Editing Object Properties
Control Model Explorer Contents Using Views Using Views

Customizing Views
Managing Views
Organize Data Display in Model Explorer Layout Options

Sorting Column Contents
Grouping by a Property
Changing the Order of Property Columns Adding Property Columns
Hiding or Removing Property Columns Marking Nonexistent Properties
Filter Objects in the Model Explorer Controlling the Set of Objects to Display Using the Row Filter
Option
Filtering Contents
Workspace Variables in Model Explorer

Finding Variables That Are Used by a Model or Block Finding Blocks That Use a Specific Variable
Finding Unused Workspace Variables
Editing Workspace Variables
Exporting Workspace Variables
Importing Workspace Variables
Search Using Model Explorer Searching in the Model Explorer The Search Bar
Showing and Hiding the Search Bar Search Bar Controls
Search Options
Search Button
Refining a Search
Model Explorer: Property Dialog Pane What You Can Do with the Dialog Pane Showing and Hiding
the Dialog Pane Editing Properties in the Dialog Pane
Finder
Find Model Objects Filter Options
Search Criteria
Model Browser
About the Model Browser Navigating with the Mouse Navigating with the Keyboard Showing Library
Links
Showing Masked Subsystems
Model Dependency Viewer

About Model Dependency Views Opening the Model Dependency Viewer Manipulating a Dependency
View Browsing Dependencies
Saving a Dependency View
Printing a Dependency View
View Linked Requirements in Models and Blocks Overview of Requirements Features in Simulink
Highlighting Requirements in a Model
Viewing Information About a Requirements Link Navigating to Requirements from a Model Filtering
Requirements in a Model
Managing Model Configurations
About Model Configurations

Multiple Configuration Sets in a Model Share a Configuration for Multiple Models
Share a Configuration Across Referenced Models
Manage a Configuration Set

Create a Configuration Set in a Model
Create a Configuration Set in the Base Workspace Open a Configuration Set in the Configuration
Parameters
Dialog Box
Activate a Configuration Set
Set Values in a Configuration Set
Copy, Delete, and Move a Configuration Set
Save a Configuration Set
Load a Saved Configuration Set
Copy Configuration Set Components
Manage a Configuration Reference

Create and Attach a Configuration Reference
Resolve a Configuration Reference
Activate a Configuration Reference
Manage Configuration Reference Across Referenced
Models
Change Parameter Values in a Referenced Configuration
Set
Save a Referenced Configuration Set
Load a Saved Referenced Configuration Set
Why is the Build Button Not Available for a Configuration
Reference?
About Configuration Sets

What Is a Configuration Set?
What Is a Freestanding Configuration Set? Model Configuration Preferences
About Configuration References

What Is a Configuration Reference?
Why Use Configuration References?
Unresolved Configuration References
Configuration Reference Limitations
Configuration References for Models with Older Simulation
Target Settings
Model Configuration Command Line Interface Overview
Load and Activate a Configuration Set at the Command
Line
Save a Configuration Set at the Command Line Create a Freestanding Configuration Set at the
Command
Line
Create and Attach a Configuration Reference at the
Command Line
Attach a Configuration ReferencetoMultipleModelsatthe
Command Line
Get Values from a Referenced Configuration Set Change Values in a Referenced Configuration Set
Obtain a Configuration Reference Handle
Userefresh When Replacing a Referenced Configuration
Set
Configuring Models for Targets with Multicore Processors
Introduction to Concurrent Execution

About Configuring Models for Concurrent Execution Supported Targets
Helpful Terms
Software Requirements
Design Considerations5 Modeling for Concurrency Simulation Limitations
Modeling Process for Concurrent Execution
Configure Your Model

Creating a Concurrent Execution Configuration Set Creating and Propagating a Configuration Reference
Analyze Baseline Customize Concurrent Execution Settings Configuring Data Transfer

Communications Configuring Periodic Tasks
Configuring Aperiodic Triggers and Tasks Map Blocks to Tasks Incrementally
Interpret Simulation Results

Introduction
Model with System Tasks
Sample Configured Model with Multiple Target Tasks How Simulink Determines Data Transfer
Requirements
Build and Download to a Multicore Target Generating Code

Configuring Embedded Coder for Native Threads
Example
Build and Download
Profile and Evaluate
Generate Profile Report
Concurrent Execution Example Model

Modeling Concurrent Execution on Multicore Targets
Command-Line Interface to Configure Models for Concurrent Execution
Exploring, Searching, and Browsing Models

Control Model Explorer Contents Using Views
Organize Data Display in Model Explorer
Filter Objects in the Model Explorer
Search Using Model Explorer
Model Explorer: Property Dialog Pane
Finder
Model Browser
View Linked Requirements in Models and Blocks
In this section...
What You Can Do Using the Model Explorer Opening the Model Explorer
The Main Toolbar
Adding Objects
Customizing the Model Explorer Interface Basic Steps for Using the Model Explorer Focusing on
Specific Elements of a Model or Chart
What You Can Do Using the Model Explorer
Use the Model Explorer to quickly view, modify, and add elements of Simulink models, Stateflow
charts, and workspace variables. The Model Explorer provides several ways for you to focus on specific
elements (for example, blocks, signals, and properties) without your having to navigate through the
model diagram or chart.
Opening the Model Explorer
To open the Model Explorer, use one of these approaches:

From the Simulink Editor View menu, select Model Explorer or select the Model Explorer icon
from the toolbar.
In an open model in the Simulink Editor, right-click a block and from the context menu, select
Explore.
In an open Stateflow chart, right-click in the drawing area and from the context menu, select Explore.
At the MATLAB command line, enterdaexplr.
By default, the Model Explorer opens with three panes (Model Hierarchy, Contents,and Dialog), a
main toolbar, and a search bar.
Search bar Main toolbar
Model Hierarchy pane Contents pane Dialog pane

Component Main toolbar
Search bar
Model
Hierarchy pane
Contents pane
Dialog pane Purpose
Execute Model Explorer commands
Perform a search within the context of the selected node in Model Hierarchy pane.
Navigate and explore model, chart, and
workspace nodes
Display and modify model or chart objects

View and change the
details of object properties
Documentation
The Main Toolbar on page 9-4
Search Using Model Explorer on page 9-63
Model Explorer: Model Hierarchy Pane on page 9-9
Model Explorer: Contents Pane on page 9-19

Model Explorer: Property Dialog Pane on page 9-70
The Main Toolbar
The main toolbar at the top of the Model Explorer provides buttons you click to perform Model Explorer
operations. Most of the toolbar buttons perform actions that you can also perform using Model Explorer
menu items.
The toolbar buttons in the following table perform actions that you cannot perform using Model
Explorer menus:
Button Usage
Bring the MATLAB window to the front.
Display the Simulink Library Browser.
If you have Simulink Verification and Validation installed, you can use additional toolbar buttons
relating to requirements links.
Adding Objects
You can use the Model Explorer to add many kinds of objects to a model, chart, or workspace. The types
of objects that you can add depend on what node you select in the Model Hierarchy pane. Use toolbar
buttons or the Add menu to add objects. The Add menu lists the kinds of objects you can add.
Customizing the Model Explorer Interface
You can customize the Model Explorer interface in several ways. This section describes how to show or
hide the main toolbar and how to control the font size.
Other ways you can customize the Model Explorer interface include:
Marking Nonexistent Properties on page 9-45
Showing and Hiding the Search Bar on page 9-64
Showing and Hiding the Dialog Pane on page 9-70
Showing and Hiding the Main Toolbar

To show or hide the main toolbar, in the Model Explorer select View > Toolbars > Main Toolbar.
Controlling the Font Size

You can change the font size in the Model Explorer panes:
To increase the font size, press the Ctrl + Plus Sign (+).
Alternatively, from the Model Explorer View menu, select Increase Font Size.
To decrease the font size, press the Ctrl + Minus Sign (-).
Alternatively, from the Model Explorer View menu, select Decrease Font Size.
Note The changes remain in effect for the Model Explorer and in the Simulink dialog boxes across
Simulink sessions.
Basic Steps for Using the Model Explorer
Use the Model Explorer to perform a wide range of activities relating to viewing and changing model
and chart elements. You can perform activities in any order, using panes in the order you choose. Your
actions in one pane often affect other panes.
For example, if you want to edit properties of objects in a model, you might use a general workflow
such as:
1 Open a model. 2 Open the Model Explorer.
3 Select the model in the Model Hierarchy pane, specifying whether the Model Explorer displays only
the current system or the whole system hierarchy of the current system
4 Control what model information the Contents pane displays, and how it displays that information, by
using a combination of:
The View > Column View option to control which property columns to display
The View > Row Filter option to control which types of objects to display
Techniques to directly manipulate column headings
5 Identify model elements with specific values, using the search bar.
6 Edit the values for model elements, in either the Contents pane or the Dialog pane. To edit workspace
variables, you can use the Variable Editor.
Focusing on Specific Elements of a Model or Chart
As you explore a model or chart, you might want to narrow the contents that you see in the Model
Explorer to particular elements of a model or chart. You can use several different techniques.
Thefollowingtablesummarizes techniques for controlling what content the Model Explorer displays and
how the contents appear.
Technique
Show partial or whole model hierarchy

contents
Use the Row Filter option

When to Use
To control how much of a hierarchical model to display
To focus on, or hide, a specific kind of a model object, such as signals
Documentation
Displaying Partial or Whole Model Hierarchy Contents on page 9-12
Using the Row Filter Option on page 9-46

Technique When to Use
Search To find objects that might not be currently displayed
Filter contents To focus on specific objects in the Contents pane, based on a search string
Documentation
Filtering Contents on page 9-48
Once you have the general set of data that you are interested in, you can use the following techniques to
organize the display of contents.
Technique Sort
Group by property column
Use column views
Add, delete, or
rearrange property table columns
When to Use
To quickly organize data for a property in ascending or

descending order
To logically group data based on values for a property
To display a named subset of property columns to apply to different kinds of

nodes in the Model Hierarchy pane
To customize property columns

Documentation
Sorting Column Contents on page 9-36
How to Group by a Property Column on page 9-39
Control Model
Explorer Contents Using Views on page 9-26
Organize Data Display in Model Explorer on page 9-36
In this section...
What You Can Do with the Model Hierarchy Pane Simulink Root
Base Workspace
Model Nodes
Displaying Partial or Whole Model Hierarchy Contents Displaying Linked Library Subsystems
LinkedLibraryandMaskedSubsystems
Navigating to the Block Diagram
What You Can Do with the Model Hierarchy Pane
The Model Hierarchy pane displays a tree-structured view of the Simulink model and Stateflow chart
hierarchy. Use the Model Hierarchy pane to navigate to the part of the model and chart hierarchy that
you want to explore.
Simulink Root
The first node in the hierarchy represents the Simulink root. Expand the root node to display nodes
representing the MATLAB workspace, Simulink models, and Stateflow charts that are in the current
session.
Base Workspace
This node represents the MATLAB workspace. The MATLAB workspace is the base workspace for
Simulink models and Stateflow charts. Variables defined in this workspace are visible to all open models
and charts.
For information about exporting and importing workspace variables, see Exporting Workspace
Variables on page 9-60 and Importing Workspace Variables on page 9-62.
To display a Configuration Preferences node in the expanded Simulink Root node, enable the View >
Show Configuration Preferences option. Selecting this node displays the preferred configuration for
new models (see Manage a Configuration Set on page 10-12). You can change the preferred
configuration by editing the displayed settings and using the Model Configuration Preferences dialog
box to save the settings (see Model Configuration Preferences on page 10-28).
Model Nodes
Expanding a model or chart node in the Model Hierarchy pane displays nodes representing the
following elements, as applicable for the models and charts you have open.
Node
Model workspace
Configuration sets
Top-level
subsystems
Description
For information about how to use the Model Explorer to work with model workspace variables, see the
following sections:
Finding Variables That Are Used by a Model or Block on page 9-52

Finding Blocks That Use a Specific Variable on page 9-55
Editing Workspace Variables on page 9-58

Exporting Workspace Variables on page 9-60
Importing Workspace Variables on page 9-62
Model Workspaces on page 4-73
For information about adding, deleting, saving, and moving configuration sets, see Manage a
Configuration Set on page 10-12.
Expand a node representing a subsystem to display underlying subsystems, if any.

Node Description
Model blocks Expand model blocks to show contents of referenced models (see Expanding Model
References on page 9-15).
Stateflow charts Expand a node representing a Stateflow chart to display the top-level states of the
chart.
Expand a node representing a state to display its substates.
Displaying Partial or Whole Model Hierarchy Contents
By default, the Model Explorer displays objects for the system that you select in the Model Hierarchy
pane. It does not display data for child systems. You can override that default, so that the Model
Explorer displays objects for the whole hierarchy of the currently selected system. To toggle between
displaying only the current system and displaying the whole system hierarchy of the current system, use
one of these techniques:
Select View > Show Current System and Below.

Click the Show Current System and Below button (
)atthetopof the Contents pane.
When you
select the Show Current System and Below option:
The Model Hierarchy pane highlights in pale blue the current system and its child systems.
After the path in the Contents of field, the text(and below) appears.
The appearance of the Show Current System and Below button at the top of the Contents pane and
in the View menu changes.
The status bar indicates the scope of the displayed objects when you hover over the Show Current
System and Below button.
Loading very large models for the current system and below can be slow. To stop the loading process at
any time, either click the Show Current System and Below button or click another node in the tree
hierarchy.
If you show the current system and below, you might want to change the view to better reflect the
displayed system contents. For details about views, see Control Model Explorer Contents Using
Views on page 9-26.
The setting for the Show Current System and Below option is persistent across Simulink sessions.
Displaying Linked Library Subsystems
By default, the Model Explorer does not display the contents of linked library subsystems in the Model
Hierarchy pane. To display the contents of linked library subsystems, use one of these approaches:
At the top of the Model Hierarchy pane, click the Show/Hide Library Links button (
).
From the View menu, select Show Library Links.
Library-linked subsystems are visible in the Contents pane, regardless of how you configure the Model
Hierarchy pane.
Note Search does not find elements in linked library or masked subsystems that are not displayed in the
Model Hierarchy pane.
By default, the Model Explorer does not display the contents of masked subsystems in the Model
Hierarchy pane. To display the contents of masked subsystems, useoneoftheseapproaches:
At the top of the Model Hierarchy pane, click the Show/Hide Masked Subsystems button (
).
From the View menu, select Show Masked Subsystems.
Masked subsystems are visible in the Contents pane, regardless of how you configure the Model
Hierarchy pane.
Linked Library and Masked Subsystems
For subsystems that are both library-linked and masked, how you set the linked library subsystems and
masked subsystems options affects which subsystems appear in the Model Hierarchy pane, as
described in the following table.
Settings
Show Library Links

Hide Masked Subsystems Hide Library Links
Show Masked Subsystems Show Library Links
Show Masked Subsystems
Subsystems Displayed in the Model Hierarchy Pane

Only library-linked, unmasked subsystems
Only masked subsystems that are not library-linked subsystems
All library-linked or masked subsystems
Select the object in the Model Hierarchy pane whose contents you want to display in the Contents
pane.
Navigating to theBlockDiagram
To open a graphical object (for example, a model, subsystem, or chart) in an editor window, right-click
the object in the Model Hierarchy pane. From the context menu, select Open.
See Manage a Configuration Set on page 10-12 for information about using the Model Hierarchy
pane to perform tasks such as adding, deleting, saving, and moving configuration sets.
To browse a model that includes Model blocks, you can expand the Model Hierarchy pane nodes of the
Model blocks. For example, the sldemo_mdlref_depgraph model includes Model blocks that reference
other models. Ifyouopenthesldemo_mdlref_depgraph model and expand that model nodeinthe Model
Hierarchy pane, you see that the model contains several Model blocks, includingheat2cost.
To browse a model
referenced by a Model block:
1 Right-click the referenced model node in the Model Hierarchy pane.

2 From the context menu, choose Open Model.
The referenced model opens.
The Model Hierarchy pane indicates that you can expand the Model block node.
The Model Hierarchy pane displays a separate expandable node for the referenced model (read-only).
The Contents pane displays objects corresponding to the Model block node (read-only).
For example, if you right-click the heat2cost Model block node and select the Open Model option, the
Contents pane displays the objects corresponding to theheat2cost Model block. You can expand
theheat2cost node.
You can browse
the contents of the referencedmodel,butyoucannoteditthe model objects that are underneath the Model
block.
Editing the Referenced Model

To edit the referenced model, expand the referenced model node in the Model Hierarchy pane. For
example, expand thesldemo_mdlref_heat2cost node:
You can now
edit the properties of object in the referenced model. For information about referenced models, see
Model Reference.
To cut, copy, and paste workspace objects from one workspace into another workspace:
1 In the Contents pane, right-click on the workspace object you want to cut or copy.
2 From the context menu, select Cut or Copy.
3
You can also cut a workspace object by selecting in the Contents pane Edit > Cut or by clicking the
Cut button (
).
You can also copy a workspace object by selecting Edit > Copy or by clicking the Copy button (
).
If you want to paste the workspace object that you cut or copied, in the Model Hierarchy pane, right-
click the workspace into which you want to paste the object, and select Paste.
You can also paste the object by selecting Edit > Paste or by clicking the Paste button (
).
You can also perform cut, copy, and paste operations by selecting an object and performing drag and
drop operations.
In this section...
Contents Pane Tabs
Horizontal Scrolling in the Object Property Table Working with the Contents Pane
Contents Pane Tabs
The Contents pane displays one of two tables containing information about models and charts,
depending on the tab that you select:
The Contents tab displays an object property table for the node that you select in the Model
Hierarchy pane.
The Search Results tab displays the search results table (see Search Using Model Explorer on page
9-63).
Optionally, you can also open a column view details section in the Contents pane. The following
graphic shows the Contents pane with the column view details section opened.
Contents tab Search Results tab

To open the column view details section, click Show Details,atthetopof the Contents pane.
Column View
Details section
Object
Property Table
section
The
Column view details section provides an interface for customizing the column view (hidden by
default).
The Object property table section displays a table of model and chart object data (open by default).
In the object property table section of the Contents tab and in the Search Results tab:
Table columns correspond to object properties (for example,Name and BlockType).
Table rows correspond to objects (for example, blocks, and states).
The objects and properties displayed in the Contents pane depend on:
The column view that you select in the Contents pane
The node thatyouselectinthe Model Hierarchy pane
The kind of object (for example, subsystem, chart, or configuration set) that you select in the Model
Hierarchy pane
The View > Row Filter options that you select
For more information about controlling which objects and properties to display inthe Contents pane,
see:
Control Model Explorer Contents Using Views on page 9-26

Filter Objects in the Model Explorer on page 9-46
The Contents of link at the top left side of the Contents pane links to the currently selected node in the
Model Hierarchy pane. The model data displayed in the Contents pane reflects the setting of the
Current System and Below option. In the following example, Contents of links to thevdp model,
which is the currently selected node.
Horizontal Scrolling in the Object Property Table
The object property table displays the first two columns (the object icon and theName property)
persistently. These columns remain visible, regardless of how far you scroll to the right.
For example, the following image shows the initial display of the object property table for thevdp model.
TheParamDataTypeStr column is too far to the righttobedisplayed.
The next image shows the results of scrolling to the right. The icon andName columns remain visible,
but now you can see theParamDataTypeStr column.
Working with the Contents Pane
The following table summarizes the key tasks to control what is displayed in the Contents.
Task
Control which kinds of objects to display.
Search within the selected set of objects.
Specify a set of properties to display based on the kind of node.
Group data based on unique values in a property column.
Manage views (for example, save and export a view).
Add, remove, or rearrange columns.
Edit object property values.
Documentation
Using the Row Filter Option on page 9-46
Control Model Explorer Contents Using Views on page 9-26
GroupingbyaPropertyonpage 9-37
Managing Views on page 9-30
Editing Object Properties on page 9-25
To open a properties dialog box for an object in the Model Hierarchy pane, right-click the object, and
from the context menu, select Properties. Alternatively, click an object and from the Edit menu, select
Properties.
You can change modifiable properties in the Contents pane (for example, a block name) by editing the
displayed value. To edit a value, first select the row that contains the value, and then click the value. An
edit control replaces the value (for example, an edit field for text values or a list for a range of values).
For workspace variables that are arrays or structures, you can use the Variable Editor. Use the edit
control to change the value of the selected property.
To assign the same property value to multiple objects in the Contents pane, select the objects and then
change one of the selected objects to have the new property value. An edit control replaces the value
with<edit>, indicating that you are doing batch editing. The Model Explorer assigns the new property
value to the other selected objects, as well.
You can also change property values using the Dialog pane. See Model Explorer: Property Dialog
Pane on page 9-70.
Control Model Explorer Contents Using Views
In this section... Using Views

Customizing Views Managing Views
Using Views
What Is a Column View?

A view in the Model Explorer is a named set of properties.
The Model Explorer uses views to specify sets of property columns to display in the Contents pane.
Foreachkindofnodeinthe Model Hierarchy pane, certain properties are most relevant for the objects
displayed in the Contents pane. For example, for a Simulink model node, such as a model or subsystem,
some properties thatareusefultodisplayinclude:
BlockType (block type)
OutDataTypeStr (output data type)
OutMin (minimum value for the block output)
Generally, a column view does not contain the total set of properties for all the objects in a node.
Specifying a subset of properties to display can streamline the task of exploring and editing model and
chart object properties and increase the density of the data displayed in the Contents pane.
What You Can Capture in a View

You can use a view to capture the following characteristics of the model information to show in the
Model Explorer:
Properties that you want to display in the Contents pane (see Customizing Views on page 9-29)
Layout of the Contents pane (for example, grouping by property, the order of property columns, and
sorting), as described in Organize Data Display in Model Explorer on page 9-36.
Use Standard Views or Customized Views You can use views in the following ways:
Use the standard views shippedwiththeModelExplorer

Customize the standard views
Create your own views
Automatically Applied Views

ThefirsttimeyouopentheModelExplorer, the software automatically applies one of the standard views to
the node you select in the Model Hierarchy pane. The Model Explorer applies a view based on the kind
of node you select.
The Model Explorer assigns one of four categories of nodes in the Model Hierarchy pane. The Model
Explorer initially associates a default view with each node category. The four node categories are:
Node Category
Simulink
Workspace
Stateflow
Other
Kinds of Hierarchy Nodes Included
Models, subsystems, and root level models Base and model
workspace objects
Stateflow charts and states
Objects that do not fit into one of the first three categories; for example, configuration sets
Initial Associated View

Block Data Types
Data Objects
Stateflow
Default
The Column View field at the top of the Contents pane displays the view that the Model Explorer is
currently using.
If you select a view. In the Contents pane, from the Column View list, you can select a different view.
If you select a different view, then the Model Explorer associates that view with the category of the
current node. For example, suppose the selected node in the Model Hierarchy pane is a Simulink
model, and the current view isData Objects.Ifyouchangethe view toSignals, then when you select
another Simulink model node, the Model Explorer uses theSignals view. See Selecting a View
Manually on page 9-28.
Selecting a View Manually

By default, the Model Explorer automatically applies a view, based on the category of node that you
select and the last view used for that node. You can manually select a view from the Column View list
that better meets your current task.
You can shift from the default mode of having the Model Explorer automatically apply views to a mode
in which you must manually select a view to change views.
To enable the manual view selection mode:

1 Select View > Column View > Manage Views.
The View Manager dialog box opens.
2 In the View Manager dialog box, click the Options button and clear Change View Automatically.
In the manual view selection mode, if you switch to a different kind of node in the Model Hierarchy
pane that has a different view associated with it, the Contents pane displays a yellow informational bar
suggesting a view to use.
Tip interface. Thetipinterfaceappearsimmediatelyabovetheobject property table.
The tip does not appear if you use automatic view selection.
To hide the currently displayed tip, from the menu button on the right-hand side of the tip bar, select
Hide This Tip.
The tip interface displays a link for changing the current view to a suggested view. To choose the
suggested view displayed in the tip bar, click the link.
Initially, the suggested view is the default view associated with a node. If you associate a different view
with a node category, then the tip suggests the most recently selected view when you select similar
nodes.
To change from manual specification of views to automatic specification, from the tip interface, select
the down arrow and then the Change View Automatically menu item.
Customizing Views
If a standard view does not meet your needs, you can either modify the view or create a new view.
You can customize the object property table represented by the current view in several ways, as
described in these sections:
Adding Property Columns on page 9-42

Hiding or Removing Property Columns on page 9-43
Changing the Order of Property Columns on page 9-41
How the Model Explorer Saves Your Customizations As you modify the object property table, you
change the current view definition.
The Model Explorer saves the following changes to the object property table as part of the column view
definition:
Grouping by property
Sorting in a column
Changing the order of property columns
Adding a property column
Hiding and removing property columns
When you change from one view to another view, the Model Explorer saves any customizations that you
have made to the previous view.
For example, suppose you use the Block Data Types view and you remove theLockScale property
column. If you then switch to use theData Objects view, and later use theBlock Data Types view again,
theBlock Data Types view no longer includes theLockScale column that you deleted.
At the end of a Simulink session, the Model Explorer saves the view customizations that you made
during that session. When you reopen the Model Explorer, Simulink uses the customized view,
reflecting any changes thatyoumadetotheviewintheprevioussession.
Managing Views
If a standard view does not meet your needs, you can either modify the view orcreateanewview.
SeeCustomizingViewsonpage9-29.
You can manage views (for example, create a new view or export a view) using the View Manager
dialog box.
Opening the View Manager Dialog Box

To open the View Manager dialog box, select the Manage Views option from either:
The View > Column View menu
The options listed when you click the Options button in the column view details section
The View Manager dialog box displays a list of defined views and provides tools for you to manage
views.
You can manage views in

several ways, including:
Creating a New View on page 9-32

Deleting Views on page 9-33
Reordering Views on page 9-33
Exporting Views on page 9-33
Importing Views on page 9-34
Resetting Views to Factory Settings on page 9-34
Creating a New View

To create a new view that has a new name, you can use one of these approaches:
Copy an existing view, rename it, and customize the view.

Create a completely new view.
After you create a new view, you can customize the view as described in Customizing Views on page
9-29.
Copying and renaming an existing view. You can build a new view by copying an existing view,
renaming it, and optionally customizing the renamed view. In the View Manager dialog box:
1 Select the view that you want to use as the starting point for your new view.
2 Click the Copy button.
A new row appears at the bottom of the View Manager table of views. The new row contains the name
of the view you copied, followed by a number in parentheses. For example, if you copy theStateflow
view, the initial name of the copied view isStateflow (1).
Creating a completely new view. To create a completely view, in the View Manager dialog box, click
the New button. A new view row appears at the bottom of the View Manager dialog box list of views.
Naming and describing a new view. Once you create a view, you can name the view and provide a
description of the view:
1 Double-clickNew View in the left column of the table of views and replace the text with a name for the
view.
2 Double-clickDescription in the table and replace the text with a description of the view.
3 Click OK.
Deleting Views
To delete a view from the Column View list of views:
1 In the View Manager dialog box, select one or more views that you want to remove from the list.
2 Click the Delete button or the Delete key.
3 Click OK.
Deleting a view using the View Manager dialog box permanently deletes that view from the Model
Explorer interface.
If you think you or someone else might want to use a view again, consider exporting the view before
you delete it (see Exporting Views on page 9-33).
Reordering Views
To change the position of a view in the Column View list, in the View Manager dialog box:
1 Select one or more views that you wish to move up or down one row in thetableofviews.
2 Click the up or down arrow buttons to the right of the table of views. Repeat this step until the view
appears where you want it to be in the table.
3 Click OK.
Exporting Views
To export views that you or others can then import, in the View Manager dialog box:
1 In the View Manager dialog box, select one or more views that you want to export.
2 Click the Export button.
An Export Views dialog box opens, with check marks next to the views that you selected.
3 Click OK.
An Export to File Name dialog box opens.
4 Navigate to the folder to which you want to export the view.
By default, the Model Explorer exports views to the MATLAB current folder.
5 Specify the file name for the exported view.
The file format is.mat.
6 Click OK.
Importing Views
To import view files from another location for use by the Model Explorer:
1 In the View Manager dialog box, click the Import button.
The Select.mat File to Import dialog box opens.
2 Navigate to the folder from which you want to import the view.
3SelecttheMAT-filecontainingthe view that you want to import and then click Open.
A confirmation dialog box opens. Click OK to import the view.
The imported view appears at the bottom of the Column View list of views.
The Model Explorer automatically renames the view if a name conflict occurs.
Resetting Views to Factory Settings

You can reset (restore) the original definition of a specific standard view (that is, a view shipped with the
Model Explorer) if that view is the current view. To do so, click the Options button in the column view
details section and select Reset This View to Factory Settings.
To reset the factory settings for allstandardviewsinonestep,intheView Manager dialog box, click the
Options button and select Reset All Views to Factory Settings.
Note When you reset all views, the Model Explorer removes all the custom views you have created.
Before you reset views to factory settings, export any views that you will want to use in the future.
Organize Data Display in Model Explorer
In this section...
Layout Options
GroupingbyaProperty
Changing the Order of Property Columns Adding Property Columns
HidingorRemovingPropertyColumns Marking Nonexistent Properties
Layout Options
You can control how the object property table and Search Results pane organize the layout of property
information by:
Sorting column contents

Grouping by a property
Changing the order of property columns
Adding a property column
Hiding and removing property columns
To sort the column contents in ascending order, click the heading of the property column. A triangle
pointing up appears in the column heading. To change the order from ascending to descending, or from
descending to ascending, click the heading of the column again.
For example, if properties are in ascending order, based on the Name property (the default), click the
heading of theName column to display objects by name, in descending order.
By default, the Contents pane displays its contents in ascending order, based on the name of the object.
Objects that have no values in any property columns appear at the end of the object property table.
Note When you group by property, the Model Explorer applies sorting of column contents within each
group.
Grouping by a Property
Organizing Contents by Property Values

When you explore a model, you might want to focus on all objects with the same property value. One
approach is to group data by a property column.
For example, suppose that you want to see all of the blocks in thef14 model. You could perform the
following search.
The search results obscure the whole path name for lower-level nodes:
By groupingonthe Path property column, you see the whole path for lower-level nodes.
You can also collapse groups to focus on specific portions of a model.
How to Group by a Property Column

To group by a property:
1 In the object property table, right-click the column heading of the property by which you want to group
contents.
You can group by object icons, such as a block icon (
), which represents a type of object. Right-click the empty column heading in the first column.
2 From the context menu, select the Group By This Column menu item.
Sorting with Grouped Data

When you group by property, the Model Explorer applies sorting of column contents within each group.
Expanding and Collapsing Grouped Data
By default, Model Explorer displays groups in expanded form. That is, all the objects in each group are
visible. You can collapse and expand groups.
To collapse the contents of a group, click the minus sign icon for that group.
To expand a group, click the plus sign.
To collapse or expand all the groups, right-click anywhere in the object property table and select either
the Collapse All Groups menu item (Shift+C)or Expand All Groups menu item (Shift+E).
Hiding the Group Column

By default, the property column that you use for grouping appears in the property table. That property
also appears in the top row for each group.
To hide the group column in the property table, use one of the following approaches:
From the View menu, clear the Show Group Column check box.
Right-click a column heading in the property table and clear the Show Group Column check box.
Persistence of Grouped Data Settings

If you group by a property, that grouping is saved as part of the view definition.
When you select a different node in the Model Hierarchy pane, the contents for the new node are
grouped by that same property. However, all groups are expanded, even if you had collapsed all groups
before switching nodes.
Grouping Search Results

You can use grouping to organize the Search Results pane. The grouping that you apply to the Search
Results pane also applies to the object property table, if that property is in the table. If the search results
include a property that is not in the object property table, and you group on that property, then the Model
Explorer removes the grouping setting that was in effect in the object property table.
Changing the Order of Property Columns
Object Icon and Name Columns Are Always First

The first two columns of every object property table are the object icon column (the column with a blank
column heading) and theName property column. You cannot hide, remove, or change the location of the
first two columns.
How to Change the Order of Property Columns

To change the order of property columns in the object property table, use one of these approaches:
In the object property table, select a column heading and drag it to a new location in the table.
This approach avoids opening the column view details section and makes it easier to move a column a
short distance to the right or left.
In the column view details section, select one or more property columns and move them up or down in
the list, using the arrow buttons to the right of the list.
This approach allows you to move several property columns in one step, but it moves the selected
columns right or left by only one column at a time. To move a property column by using the view details
interface:
1 In the Display column names in this order list on the right side of the column view details section,
select one or more property columns that you want to move.
2 Click the Move column left in view button (
)orthe Move column right in view button (
).
Adding Property Columns
To add property columns to a view:
1If you do not have the column view details section of the Contents pane already open, then at the top
of the Contents pane, select Show Details.
2 In the list of properties on left side of the column view details section, select one or more properties
that you want to add.
The list displays property names in alphabetical order. You can use the Find Properties search box in
the column view details section to search for properties that contain the text string that you enter. You
can specify the scope of the search with the From list to the right of the search box.
3 In the list of column names on the right side, select the property column
thatyouwanttobetotheleftofthepropertycolumnsyouinsert.
4 Click the Display property as column in view button ( )
Adding a Path Property Column

The Model Explorer provides a shortcut for adding aPath property column to aview. Toadd aPath
property column:
1 Right-click the column heading in the object property table to the right of which you want to insert
aPath column.
2 From the context menu, select Insert Path.
Hiding or Removing Property Columns
You can choose between two approaches to hide (remove) a property column from the object property
table. Hiding and removing a column both have the same result. You can:
Hide a column using the context menu for a column heading. This approach avoids needing to open the
column view details section.
Remove a column using the column view details interface. This approach allows you to delete several
properties in one step.
Hiding a Column Using the Column Heading Context Menu
1 Right-click the column heading of the column that you want to remove. 2 From the context menu,
select Hide.
Removing a Column Using the Column View Details Interface
1 If you do not have the column view details section of the Contents pane already open, then at the top
of the Contents pane, select Show Details.
2 In the column view details section of the Contents pane, in the Display columnnamesinthisorder list,
select one or more properties that you want to remove.
3 Click the Remove column from view button (
)orthe Delete key.
Inserting Recently Hidden or Removed Columns

The Model Explorer maintains a list of columns you hide or remove for each view during a Simulink
session.
To add a recently hidden or removed column back into a view:

1 Right-click the column heading of the column to the right of which you want to insert a recently
hidden column.
2 From the context menu, select Insert Recently Hidden Columns.
3 Select the column that you want to insert.
See Hiding or Removing Property Columns on page 9-43.
Marking Nonexistent Properties
Usually, some of the properties that the Contents pane displays do not apply to all the displayed objects
(in other words, some objects do not have values set). By default, the Model Explorer displays a dash ()
to mark properties that do not haveavalue.
If you want the Model Explorer to display a blank (instead of the default dash) in property
cellsthathavenovalues,clearthe View > Show Nonexistent Properties as option. The Contents pane
looks similar to the following graphic:
Filter Objects in the Model Explorer
In this section...
Controlling the Set of Objects to Display Using the Row Filter Option
Filtering Contents
Controlling the Set of Objects to Display
Two techniques that you can use to control the set of objects that the Contents pane displays are:
Using the Row Filter option
Filtering contents
For a summary of other techniques, see Focusing on Specific Elements of a Model or Chart on page
9-7.
Using the Row Filter Option
You can filter the kinds of objects that the Contents pane displays:
1Open the Row Filter options menu. In the Model Explorer, at the top-right corner of the Contents
pane, click the Row Filter button.
An alternative way to open the Row Filter menu is to select View > Row Filter.
By default, the Contents pane displays these kinds of objects for the selected node:
Blocks
Signals and connections
Stateflow states, functions, and boxes
Stateflow events
Stateflow data
2 Clear the kinds of objects that you do not want to display in the Contents pane, or enable any cleared
options to display more kinds of objects. For example, clear All Signals/Connections to prevent the
display of signal and connection objects in the Contents pane.
Object Count
The top-right portion of the Contents pane includes an object counter, indicating how many objects the
Contents pane is displaying.
When you use the Row Filter option to filter objects, the object count indicator reflects that the
Contents pane displays a subset of all the model and chart objects.
To view an explanation of the current object count, click the object count link (for example,12 of 25
objects). That link displays a pop-up information box:
Filtering Contents
To refine the display of objects that are currently displayed in the Contents pane, you can use the Filter
Contents text box at the top of the Contents pane to specify search strings for filtering a subset of
objects.
Using the Filter Contents text box can help you to find specific objects within the set of objects, based
on a particular object name, property value, or property that is of interest to you. For example, if you
enter the text string fuel in the Filter Contents edit box, the Model Explorer displays results similar to
those shown above. The results highlight the text string that you specified.
Specifying Filter Text Strings

As you enter text in the Filter Contents text box, the Model Explorer performs a dynamic search,
displaying results that reflect the text as you enter it.
The text strings you enter must be in the format consistent with the guidelines described in the following
sections.
Case Sensitivity. By default, the Model Explorer ignores case as it performs the filtering.
To specify that you want the Model Explorer to respect case sensitivity for
atextstringthatyouenter,putthattextstringinquotationmarks. For example, if you want to restrict the
filtering to display only objects that include the textFuel (with a capitalF), enter"Fuel" (with quotation
marks).
Specifying Property Values. To restrict the filtering to apply to values for a specific property, specify
the property name followed by a colon (:) and then the value. For example, to filter the contents to
display only objects whoseOutDataTypeStr property has a value that includesInherit,enter
OutDataTypeStr: Inherit (alternatively, you could put the whole string in quotation marks to enforce case
sensitivity):
Wildcards and MATLAB Expressions Not Supported. The Model Explorer does not recognize
wildcard characters, such as an asterisk (*), as having any special meaning. For example, if you
enterfuel* in the Filter Contents text box, you get no results, even if several objects contain the text
stringfuel.
Also, if you specify a MATLAB expression, in the Filter Contents text box, the Model Explorer
interprets that string as literal text, not as a MATLAB expression.
Clearing the Filtered Contents

To redisplay the object property table as it appeared before you filtered the contents, click the X in the
Filter Contents text box.
Filtering Removes Grouping

If you have set up grouping on a column, then when you filtering contents, the Model Explorer does not
retain that grouping.
In this section...
Finding Variables That Are Used by a Model or Block Finding Blocks That Use a Specific Variable
Finding Variables That Are Used by a Model or Block
In the Model Explorer, you can get a list of variables that a model or block uses. The following approach
is one way to get that list of variables:
1 In the Contents pane, right-click the block for which you want to find the variables that it uses.
2 Select the Find Referenced Variables menu item.
Model Explorer returns results similar to these:

For performance, Model Explorer uses cached information from the last compiled version of the model.
If you want to recompile the model, either do so manually or, in the Model Explorer, set the Update
diagram field to yes and repeat the search.
You can also use the following approaches to find variables that a model or block uses:
In the Model Explorer, in the Model Hierarchy pane, right-click a block or modelnodeandselectthe
Find Referenced Variables menu item.
In the Model Explorer, in the search bar, use thefor Referenced Variables search type option.
In the Simulink Editor, right-click a block, subsystem, or in the canvas and select the Find Referenced
Variables menu item. Clicking the canvas returns results for the whole model.
The Simulink.findVars function provides additional options for returning information about workspace
variables that is not available from the Model ExplorerorSimulinkEditor.
For information about limitations when finding referenced variables, see the Simulink.findVars
documentation.
Using the Set of Returned Variables

For a variable in the set of returned variables, you can find the blocks that use that variable (for details,
see Finding Blocks That Use a Specific Variable on page 9-55). Also, you can export variables from
the returned set of variables. For details, see Exporting Workspace Variables on page 9-60.
Finding Blocks That Use a Specific Variable
You can use the Model Explorer to get a list of blocks that use a specific workspace variable. One way
to get that list of blocks is to right-click a variable in the Contents pane and select the Find Where
Used menu item. For example:
1 Open thef14 model.

2 Open the Model Explorer.
3 In the Model Hierarchy pane, select theBase Workspace node.
4 In the Contents pane, right-click theMq variable and select the Find Where Used menu item.
5 In the Hierarchy dialog box that appears, selectf14.TheModelExplorer displays output similar to this:
The property columns whose values include Mq represent the block parameters that use theMq variable.
If those property columns are not already in the view, then the Model Explorer adds them to the end of
the search results display.
You can also find blocks that use a specific variable, by using one of these approaches:
In the search bar, select thefor Variable Usage search type option.
In the Search Results pane, right-click a variable and select the Find Where Used menu item.
If you do not find the variable that you are looking for because that variable is not in the currently
selected system, try selecting View > Show Current System and Below and repeat the search.
YoucanusetheModelExplorertogetalist of variables that are defined in a workspace but not used by a

model or block. One way to get that list of variables is to right-click a workspace name in the Model
Hierarchy pane and select the Find Unused Variables menu item. For example:
1 Open thef14 model.

3 In the search toolbar, set the Update diagram field toyes.
4In the Model Hierarchy pane, right-click theBase Workspace node and select the Find Unused
Variables menu item.
5 The Model Explorer displays output similar to this:

The Simulink.findVars function provides additional options for returning information about unused
workspace variables that is not available from the Model Explorer or Simulink Editor.
In the Model Explorer Contents pane, you can use the Variable Editor to edit variables from the
MATLAB workspace or model workspace. The Variable Editor is available for editing large arrays and
structures.
To open the Variable Editor for a variable that is an array or structure:

1ClicktheValuecellforthevariable.
2 Select the Variable Editor icon.
The Variable Editor opens:
Right-click in
an edit box to open a context menu with several editing options:
You can resize and move the Variable Editor. The Contents pane reflects the edits that you make in the
Variable Editor.
Whenyoufinishediting,theVariable Editor closes when you click the Close button in the upper right
corner of the editor or when you click outside of the editor.
You can export (save) a set of variables listed in the Model Explorer, exporting either individual
variables or all the variables in the base or model workspace.
One possible workflow is to export the set of variables returned with the Find Referenced Variables
option or theSimulink.findVars function. For details, see Finding Variables That Are Used by a Model
or Block on page 9-52.
Note All the variables that you export must be from the same workspace.
To export all the variables in a workspace in the Model Explorer to a MATLAB code file orMAT-file:
1 Select the variables that you want to export.
aTo select all the variables in a workspace, right-click the workspace node (for example,Base
Workspace)andselectthe Export menu item. For example:
bTo select individual variables, in the Contents pane, select the variables that you want to export.
Right-click one of the highlighted variables and select the Export Selected menu item.
If the Contents pane has data grouped by a property, selecting the top line in a group does not select all
the variables in that group. For details about grouped data, seeGrouping by a Property on page 9-37.
2 Specify whether to save the variables in a MATLAB code file or a MAT-file.
TheMATLABcodefileformatiseasiertoread,iseditable,andsupports version control. The MAT-file format

is binary, which has performance advantages.
IfyouspecifyaMATLABcodefileformat,theModelExplorermaycreate an associated MAT-file, reflecting

the name of the MATLAB code file, but with an extension of.mat instead of.m.
3Specify a name and location for the file.

4If the file already exists, Model Explorer displays a dialog box asking you to choose one of these
options:
Overwrite entire file

Replaces all variables in the target file with the selected variables, which are stored in alphabetical
order.
Update variables that exist in file and append new variables to file
Updates existing variables in place and appends new variables.

Only update variables that exist in file
Updates existing variables, but does not add any new variables, which eliminates potentially
extraneous variables.
You can import (load) a set of variables from a file into the base workspace or into a model workspace
using the Model Explorer. When you import variables into a workspace, the Model Explorer overwrites
existing variables and adds any new variables.
To import variables into a workspace:

1 In the Model Hierarchy pane, right-click the workspace into which you want to import variables.
2 Select the Import menu item.
3IntheImportfromFiledialogbox,selectaMATLABcodefileorMAT-file for the variables that you want to
import.
Note If you import a MATLAB code file, then Simulink also imports the associated MAT-file.
Search Using Model Explorer
In this section...
Searching in the Model Explorer The Search Bar
Showing and Hiding the Search Bar Search Bar Controls
Search Options
Search Button
Refining a Search
Searching in the Model Explorer
Use the Model Explorer search bar to search for specific objects from the node you select in the Model
Hierarchy pane.
The Model Explorer displays search results in the Search Results tab of the Contents pane.
The search results appear in a table that is similar to the object property table in the Contents tab. The
search results table uses the current column view (the object property table) definition as a starting point,
and adds relevant properties that are not already included in the current view. Any additional property
columns added to the Search Results pane do not affect the view definition.
If you modify the property columns in the search results table that also appear in the property table view,
the changes you make affect both tables. For example, if you hideOutMax column in the search results
table, and the OutMax column was also in the object property view table, then theOutMax
columnishiddeninbothtables. However, if in the search results table you reorder where theComplexity
column appears, if the view does not include theComplexity property, then that change to the search
results table does not affect the view.
You can edit property values in the search results table.
The Search Bar
The search bar appears at the top of the Model Explorer window.
Search
bar
Showing and Hiding the Search Bar
By default, the search bar is visible. To show or hide the search bar, select or clear the View > Toolbars
> Search Bar option.
Search Bar Controls
The search bar includes the following controls:

Select Specify Select
search search search
type criteria optionsStart
search
Search Type
Use the Search Type control to specify the type of objects or properties to include in the search.
Search Type Option by Name

by Property Name
by Property Value
by Block Type
by Stateflow Type
for Variable Usage
for Referenced Variables
Description
Searches a model or chart for all objects that have the specified string in thenameoftheobject. See
Search Strings on page 9-68.
Searches for objects that have a specified property. Specify the target property name from a list of
properties that objects in the search domain can have.
Searches for objects with a property valuethatmatchesthevalueyou specify. Specify the name of the
property,thevaluetobematched, and the type of match (for example, equals, less than, or greater than).
See Search Strings on page 9-68.
Searches for blocks of a specified block type. Select the target block type from the list of types contained
in the currently selected model.
Searches for Stateflow objects of a specified type.
Searches for blocks that use

variables defined in a workspace. Select the base workspace or a model workspace (model name) and,
optionally, the name of a variable. See Search Strings on page 9-68.
Searches for variables that a model or block uses. Specify the name of the model or block in the by
System field. The model or block must be in the Model Hierarchy pane.
Search Type Option
for Unused Variables

for Library Links
by Class
for Fixed Point Capable
for Model References
by Dialog Prompt
by String
Description
Searches for variables that are defined in a workspace but not used by any model or block. Select the
name of the workspace from the drop-down list for the in Workspace field.
Searches for library links in the current model.

Searches for Simulink objects of a specified class.
Searches a model for all blocks that support fixed-point computations. Searches a model for references
to other models.
Searches a model for all objects whose dialogs contain the prompt you specify. See Search Strings on
page 9-68.
Searches a model for all objects in which the string you specify occurs. See Search Strings on page
9-68.
Search Options
Use the Search Options control to specify the scope and how to apply search strings.
Search Option
Match Whole String
Match Case Description
Do not allow partial string matches (for example, do not allowsub to matchsubstring).
Considers case when matching strings (for example,Gain does not matchgain).
Search Option
Regular Expression
Evaluate Property Values During Search
Refine Search Description
Considers a string to be matched as a regular expression.
Applies only for searches by property value. If enabled, the option causes the Model Explorer to
evaluate the value of each property as a MATLAB expression and compare the result to the search value.
If this option is disabled (the default), the Model Explorer compares the unevaluated property value to
the search value.
Initiates a secondary search that provides additional search criteria to refine the initial search results. The
second search operation searches for objects that meet both the original and the new search criteria (see
Refining a Search on page 9-69).
By default, the Model Explorer searches for objects in the system that you select in the Model Hierarchy
pane. It does not search in child systems. You can override that default, so that the Model Explorer
searches for objects in the whole hierarchy of the currently selected system. To toggle between searching
only in the current system and searching in the whole system hierarchy of the current system, use one of
these techniques:
Select View > Show Current System and Below.

Click the Show Current System and Below button at the top of the Contents pane.
Search Strings
By default, search strings are case-insensitive and are treated as regular expressions.
By default, the search allows partial string matches. You cannot use wildcard characters in search
strings. For example, if you enter*1 as a name search string, you get no search results unless there is an
item whose name starts with the two characters*1.Ifthereisanout1 item, the search results do not include
that item.
Search Button
Click the Search button to start the search specified by the current settings of the search bar on the
object selected in the Model Hierarchy pane. The Model Explorer displays the results of the search in
the Search Results pane.
The top of the Search Results pane displays a summary of the results, including the scope of the search
and the search criteria that you specified.
You can edit the results displayed in the Search Results pane. For example, to change all objects found
by a search to have the same property value, select the objects in the Search Results pane and change
the property value of one of the objects.
RefiningaSearch
To refine the previous search, in the search bar, click the Select Search Options button (
)andselect Refine Search.A Refine button replaces
the Search button on the search bar. Use the search bar to define new search criteria and then click the
Refine button. The Model Explorer searches for objects that match both the previous search criteria and
the new criteria.
In this section...
WhatYouCanDowiththeDialogPane Showing and Hiding the Dialog Pane Editing Properties in the
Dialog Pane
What You Can Do with the Dialog Pane
You can use the Dialog pane to view and change properties of objects that you select in the Model
Hierarchy pane or in the Contents pane.
Showing and Hiding the Dialog Pane
By default, the Dialog pane appears in the Model Explorer, to the right of the Contents pane. To show
or hide the Dialog pane, use one of these approaches:
From the View menu, select Show Dialog Pane.

From the main toolbar, click the Dialog View button ( ).
Editing Properties in the Dialog Pane
To edit property values using the Dialog pane:

1 In the Contents pane, select an object (such as a block or signal). The Dialog pane displays the
properties of the object you selected.
2 Change a property (for example, the port number of an Outport block) in the Dialog pane.
3 Click Apply to accept the change, or click Revert to return to the original value.
By default, clicking outside a dialog box with unapplied changes causes the Apply Changes dialog box
to appear:
Click Apply to accept the changes or Ignore to

revert to the original settings.
To prevent display of the Apply Changes dialog box:
1 In the dialog box, click theInthefutureApplyorIgnore(whicheverI select) without asking check box.
2 If you want Simulink to apply changes without warning you, press Apply. If you want Simulink to
ignore changes without warning you, press Ignore.
To restore display of the Apply Changes dialog box, from the Tools menu, select Prompt if dialog has
unapplied changes.
Finder
In this section... Find Model Objects Filter Options

Search Criteria
Find Model Objects
Use the Finder to locate blocks, signals, states, or other objects in a model.
1 Open the Finder. In the Simulink Editor, either select Edit > Find,or press Ctrl+F.
2 In the Filter
options area, specify the kinds of objects to look for, and wheretosearchforthem.
SeeFilterOptionsonpage9-75.
3 In the Search criteria area, specify the criteria that objects must meet to satisfy your search request.
See Search Criteria on page 9-76.
4 If you have more than one system or subsystem open, click the Start in system list. From this list,
select the system or subsystem where you want the search to begin.
5Click Find.
The Finder searches the selected system for objects that meet the criteria that you have specified. Any
objects that satisfy the criteria appear in the results panel at the bottom of the dialog box.
Display a Found Object
To display a found object, double-click its entry in the search results list. Simulink opens the system or
subsystem that contains the object (if necessary) and highlights and selects the object.
To sort the results list based on the values in a column, click the button at the top of that column. For
example, to sort the results by object type, click the Type button. To sort the list in ascending order,
click the button once. To sort the list in descending order, click the button twice.
To display the parameters or properties of an object, right-click the object in the list. From the context
menu, select Parameter or Properties. If you close a model that has objects in the Finder search results
list, then double-clicking a found object from that model does not open the model. To open an object
that was in the Finder search results list, simply rerun the search by clicking the Find button.
Filter Options
To specify the kinds of objects to look for, and where to search for them, use the Filter options panel.
Object Type List
Theobjecttypelistliststhetypesof objects that the Finder can find. To exclude a type of object from the
Finder search, clear the check box for the object.
Specifying Kinds of Systems To Search

You can configure the Finder to search inside masked systems, linked library systems, and referenced
models. The search starts with the system that you specify in the Start in system field.
Object Type Option

Look inside masked systems Look inside linked systems Look inside referenced models Where the
Finder Searches Inside masked subsystems
Inside subsystems linked to libraries
Inside referenced models, down through a model reference hierarchy
Note The Finder loads unopened referenced models. You can stop the search by using the pop-up cancel
dialog box.
If you select more than one option, then the Finder searches in systems that fit any of the specified
options. For example, if you select the Look inside linked systems and Look inside referenced models
options, then the Finder:
Searches in linked library systems and referenced models that are not in a masked system
Does not search inside:
- Masked systems, including those that are in linked library systems or referenced models
- Linked library systems or model referenced models, if the system or model is in a masked system
Search Criteria
To specify the criteria that objects must meet to satisfy your search request, use the Search criteria
panel.
Basic
To search for an object whose name matches a specified text string, use the Basic panel. Enter search
text in the Find what edit box. To reuse previous search text, select the appropriate search text from the
dropdown list.
To include dialog parameters in the search, select Search block dialog parameters.
Advanced
To specify a set of as many as seven properties that an object must have to satisfy your search request,
use the Advanced panel.
To specify a property, enter its name in one of the cells in the Property column or select the property
from the property list of a cell. To display the property list, select the down arrow button next to the cell.
Next enter the value of the property in the Value column. When you enter a property name, the Finder
checks the check box next to the property name in the Select column. This indicates that the property is
to be included in the search. To exclude the property, clear the check box.
Match case
Select this option if you want the Finder to consider case when matching search text against the value of
an object property.
Other match options

Next to the Match case option is a dropdown list that specifies other match options.
Matches search string

Specifies a match if the property value and the search text are identical except possibly for case.
Contains search string
Specifies a match if a property value includes the search text.

Regular expression
Specifies that the search text should be treated as a regular expression when matched against property
values. The following characters have special meanings when they appear in a regular expression.
Character Meaning
^ Matches start of string.
$ Matches end of string.
. Matches any character.
\ Escape character. Causes the next character to have its ordinary meaning. For example, the regular
expression \.. matches.a and.2 and any other two-character string that begins with a period.
Character Meaning
* Matches zero or more instances of the preceding character. For example,ba* matchesb,ba,baa,andso
on.
+ Matches one or more instances of the preceding character. For example,ba+ matchesba,baa,etc.
[] Indicates a set of characters that can match the current character. A hyphen can be used to indicate a
range of characters. For example,[a-zA-Z0-9_]+ matches foo_bar1 but notfoo$bar.A^ indicates a match
when the current character is not one of the following characters. For example,[^0-9] matches any
character that is not a digit.
\w Matches a word character (same as[a-z_A-Z0-9]). \W Matches a nonword character (same as[^a-
z_A-Z0-9]). \d Matches a digit (same as[0-9]).
\D Matches a nondigit (same as[^0-9]).
\s Matches white space (same as[ \t\r\n\f]). \S Matchesnonwhitespace(sameas[^ \t\r\n\f]).
\<WORD\> MatchesWORD whereWORD is any string of word characters surrounded by white space.
Model Browser
In this section...
About the Model Browser Navigating with the Mouse Navigating with the Keyboard Showing
Library Links
About the Model Browser
The Model Browser enables you to
Navigate a model hierarchically

Open systems in a model
Determine the blocks contained in a model
Note The browser is available only on Microsoft Windows platforms.

To display the Model Browser, in the Simulink Editor, select View > Model Browser > Show Model
Browser.
Model Browser
The model window splits into two panes. The left pane displays the browser, a tree-structured view of
the block diagram displayed in the right pane.
Note The Browser initially visible preference causes Simulink to open models by default in the Model
Browser. To set this preference, in the Simulink Editor, select File > Simulink Preferences.
The top entry in the tree view corresponds to your model. A button next to the model name allows you
to expand or contract the tree view. The expanded view shows the models subsystems. A button next to
a subsystem indicates that the subsystem itself contains subsystems. You can use the button to list the
subsystems children. To view the block diagram of the model or any subsystem displayed in the tree
view, select the subsystem. You can use either the mouse or the keyboard to navigate quickly to any
subsystem inthetreeview.
Navigating with the Mouse
Click any subsystem visible in the tree view to select it. Click the + button next to any subsystem to list
the subsystems that it contains. Click the button again to contract the entry.
Navigating with the Keyboard
Use the up/down arrows to move the current selection up or down the tree view. Use the left/right arrow
or +/- keys on your numeric keypad to expand an entry that contains subsystems.
Showing Library Links
The Model Browser can include or omit library links from the tree view of a model. Use the Preferences
dialog box to specify whether to display library links by default. To toggle display of library links, select
View > Model Browser > Include Library Links.
The Model Browser can include or omit masked subsystems from the tree view. If the tree view includes
masked subsystems, selecting a masked subsystem in the tree view displays its block diagram in the
diagram view. Use the Preferences dialog box to specify whether to display masked subsystems by
default. To toggle display of masked subsystems, select View > Model Browser > Include Systems
with Mask Parameters.
In this section...
About Model Dependency Views Opening the Model Dependency Viewer Manipulating a
Dependency View Browsing Dependencies
About Model Dependency Views
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 referencedlibrariesandmodels. Toidentifyandpackage all
required files, see instead Analyze Model Dependencies on page 13-128.
The Model Dependency Viewer allows you to choose between the following types of dependency views
of a model reference hierarchy.
File Dependency View on page 9-83

Referenced Model Instances View on page 9-85
Processor-in-the-Loop Mode Indicator on page 9-87
Warning Icon on page 9-88
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 theaero_guidance model references two
libraries:aerospace andsimulink_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.
Legend
Referenced Model Instances View

A referenced model instances view shows every reference to a model in a model reference hierarchy
(see Model Reference) 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
atsldemo_mdlref_depgraph contains two references to the modelsldemo_mdlref_F2C.
In an instance view, boxes represent a top model and model references. Boxes representing accelerated-
mode instances (see Referenced Model Simulation Modes on page 6-21) 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 have a lock icon, and the model name has the.slxp
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
Specify the Simulation Mode on page 6-23). For example, the following dependency instance view
indicates that the model namedrtwdemo_pil_component runs in processor-in-the-loop mode.
Warning Icon
An instance view displays warning icons on instance boxes to indicate that a reference is 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.
The warning icon is a yellow triangle

.
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 Analysis > Model Dependencies > Model Dependency Viewer, then select the type of view
you want to see:
Models & Libraries
Models Only
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 on page 9-90

Excluding Block Libraries from a File Dependency View on page 9-90
Including Simulink Blocksets in a File Dependency View on page 9-90
Changing View Orientation on page 9-91
Expanding or Collapsing Views on page 9-91
Zooming a Dependency View on page 9-92
Moving a Dependency View on page 9-92
Rearranging a Dependency View on page 9-93
Displaying and Hiding a Dependency Views Legend on page 9-93
Displaying Full Paths of Referenced Model Instances on page 9-93
Refreshing a Dependency View on page 9-94
Changing Dependency View Type
You can change the type of dependency view displayed in the viewer.
To change the type of dependency view, in the Model Dependency Viewer:
Select View > Dependency Type > Model File Dependencies (see File Dependency View on page
9-83 )
or
Select View > Dependency Type > Referenced Model Instances (see Referenced Model Instances
View on page 9-85 ).
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
MathWorks block libraries when View > Include Libraries is selected.
To include libraries supplied by 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.
Expand/Collapse Button
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:
1Movethecursorovertheview.
2 Press your keyboards space bar and your mouses 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 Views Legend The dependency view can display a legend that
identifies the model in the viewandthedateandtimetheviewwascreated.
To display or hide a dependency views legend:

Select View > Show Legend from the viewers menu bar.
Displaying Full Paths of Referenced Model Instances In an instance view (see Referenced Model
Instances View on page 9-85) , 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 viewers menu bar.
Browsing Dependencies
You can use a dependency view to browse a models 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 viewers 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 viewers menu bar, then enter a name for the view.
To reopentheview:
Select File > Open from any viewers menu bar, then select the view you want to open.
To print a dependency view:

Select File > Print from the dependency viewers menu bar.
View Linked Requirements in Models and Blocks
In this section...
Overview of Requirements Features in Simulink Highlighting Requirements in a Model
Viewing Information About a Requirements Link Navigating to Requirements from a Model
Filtering Requirements in a Model
Overview of Requirements Features in Simulink
If your Simulink model has links to requirements in external documents, you can review these links. To
identify which model objects satisfy certain design requirements, use the following requirements
features available in Simulink software:
Highlighting objects in your model that have links to external requirements

Viewing information about a requirements link
Navigating from a model object to its associated requirement
Filtering requirements highlighting based on specified keywords
Having a Simulink Verification and Validation license enables you to perform the following additional
tasks, using the Requirements Management Interface (RMI):
Adding new requirements

Changing existing requirements
Deleting existing requirements
Applying user tags to requirements
Creating reports about requirements links in your model
Checking the validity of the links between the model objects and the requirements documents
Highlighting Requirements in a Model
You can highlight a model to identify which objects in the model have links to requirements in external
documents. Both the Simulink Editor and the Model Explorer provide this capability.
Highlighting a Model Using the Simulink Editor on page 9-97
Highlighting a Model Using the Model Explorer on page 9-98
Note If your model contains a Model block whose referenced model contains requirements, those
requirements are not highlighted. If you have Simulink Verification and Validation, you can view this
information only in requirements reports. To generate requirements information for referenced models
and then see highlighted snapshots of those requirements, follow the steps in Report for Requirements
in Model Blocks.
Highlighting a Model Using the Simulink Editor

If you are working in the Simulink Editor and want to see which model objects in
theslvnvdemo_fuelsys_officereq model have requirements, follow these steps:
1 Open the example model:

slvnvdemo_fuelsys_officereq
2 Select Analysis > Requirements > Highlight Model.
Two types of highlighting indicate model objects with requirements:
Yellow highlighting indicates objects that have requirements links for the object itself.
Orange outline indicates objects, such as subsystems, whose child objects have requirements links.
Objects that do not have requirements are colored gray.

3To remove the highlighting from the model, select Analysis > Requirements > Unhighlight Model.
Alternatively, you can right-click anywhere in the model, and select Remove Highlighting.
While a model is highlighted, you can still manage the model and its contents.
Highlighting a Model Using the Model Explorer

If you are working in Model Explorer and want to see which model objects have requirements, follow
these steps:

2 Select View > Model Explorer.
3 To highlight all model objects with requirements, click the Highlight items with requirements on
model icon (
).
The Simulink Editor window opens, and all objects in the model with requirements are highlighted.
Note If you are running a 64-bit version of MATLAB, when you navigate to a requirement in a PDF file,
the file opens at the top of the page, not at the bookmark location.
Viewing Information About a Requirements Link
Using Simulink, you can view detailed information about a requirements link, such as identifying the
location and type of document that contains the requirement.
Note You can only modify the requirements information if you have a Simulink Verification and
Validation license.
For example, to view information about the requirements link from the MAP Sensor block in
theslvnvdemo_fuelsys_officereq example model, follow these steps:

2 Right-click the MAP sensor block, and select Requirements > Edit/Add Links.
The Requirements dialog box opens and displays the following information about the requirements link:
The description of the link (which is the actual text of the requirement).
The Microsoft Excel workbook named

slvnvdemo_FuelSys_TestScenarios.xlsx, which contains the linked requirement.
The requirements text, which appears in the named cell Simulink_requirement_item_2 in the
workbook.
The user tagtest, which is associated with this requirement.
Navigating to Requirements from a Model
Navigating from the Model Object

You can navigate directly from a model object to that objects associated requirement. When you take
these steps, the external requirements document opens in the application, with the requirements text
highlighted.

2 Open the fuel rate controller subsystem.
3 To open the linked requirement, right-click the Airflow calculation subsystem and select
Requirements > 1. Mass airflow estimation.
The Microsoft Word document

slvnvdemo_FuelSys_DesignDescription.docx, opens with the section 2.1 Mass airflow estimation
selected.
Note If you are running a 64-bit version of MATLAB, when you navigate to a requirement in a PDF file,
the file opens at the top of the page, not at the bookmark location.
Navigating from a System Requirements Block

Sometimes you want to see all the requirements links at a given level of the model hierarchy. In such
cases, you can insert a System Requirements block to collect all requirements links in a model or
subsystem. The System Requirements block lists requirements links for the model or subsystem in
which it resides; it does not list requirements links for model objects inside that model or subsystem,
because those are at a different level of the model hierarchy.
In the following example, you insert a System Requirements block at the top level of
theslvnvdemo_fuelsys_officereq model, and navigate to the requirements using the links inside the
block.

2 In the Simulink Editor, select Analysis > Requirements > Highlight Model.
3 Open the fuel rate controller subsystem.
The Airflow calculation subsystem has a requirements link.
4 Open the Airflow calculation subsystem.
5 In the Simulink Editor, select View > Library Browser.
6 On the Libraries pane, select Simulink Verification and Validation.
This library contains only one blockthe System Requirements block.
7 Drag a System Requirements block into the Airflow calculation subsystem.
The RMI software collects and displays any requirements links for that subsystem in the System
Requirements block.
8 In the System Requirements block, double-click 1. Mass airflow subsystem.
The Microsoft Word document,

slvnvdemo_FuelSys_DesignDescription.docx,opens,withthesection 2.1 Mass airflow estimation
selected.
Filtering Requirements in a Model
Filtering Requirements Highlighting by User Tag on page 9-102

Filtering Options for Highlighting Requirements on page 9-103
Filtering Requirements Highlighting by User Tag

Some requirements links in your model can have one or more associated user tags. User tags are
keywords that you create to categorize a requirement, for example,design ortest.
For example,intheslvnvdemo_fuelsys_officereq model, the requirements link from the MAP sensor
block has the user tagtest.
To highlight only all the blocks that have a requirement with the user tag test:
2 In the Simulink Editor, select Analysis > Requirements > Settings.
The Requirements Settings dialog box opens. If you do not have a Simulink Verification and Validation
license, the Filters tab is the only option available.
By default, your model has no requirements filtering enabled.

3 Select Filter links by user tags when highlighting and reporting requirements.
4 In the Include links with any of these tags text box, deletedesign, and entertest.
5 Press Enter.
6 Highlight theslvnvdemo_fuelsys_officereq model for requirements. Select Analysis > Requirements
> Highlight Model.
In the top-level model, only the MAP sensor block and the Test inputs block are highlighted.
7Todisablethefilteringbyusertag,select Analysis > Requirements > Settings,andclear Filter links by

user tags when highlighting and reporting requirements.
The model highlighting updates immediately.
Filtering Options for Highlighting Requirements

On the Filters tab, you select options that designate which objects with requirements are highlighted.
The following table describes these settings, which apply to all requirements in your model for the
duration of your MATLAB session.
Option
Filter links by user tags when highlighting and reporting requirements

Description
Enables filtering for highlighting and reporting, based on specified user tags.
Include links with any of these tags

Exclude links with any of these tags
Highlights all objects whose

requirements match at least one of the specified user tags. The tag names must match exactly. Separate
multiple user tags with commas or spaces.
Excludes from the highlighting all objects whose requirements match at least one of the specified user
tags. The tag names must match exactly. Separate multiple user tags with commas or spaces.
Option
Apply same filters in context menus
Under Link type filters, Disable DOORS surrogate item links in context menus
Description
Disables navigation links in context menus for all objects whose requirements do not match at least one
of the specified user tags.
Disables links to IBM Rational DOORS surrogate items from the context menus when you right-
click a model object. This option does not depend on current user tag filters.
Managing Model Configurations

Multiple Configuration Sets in a Model
Share a Configuration for Multiple Models
Model Configuration Command Line Interface
A model configuration is a named set of values for the parameters of a model. It is referred to as a
configuration set. Every new model is created with a default configuration set, calledConfiguration, that
initially specifies default values for the model parameters. You can change the default values for new
models by setting the Model Configuration Preferences. For more information, see Model
Configuration Preferences on page 10-28.
You can subsequently create and modify additional configuration sets and associate them with the
model. The configuration sets associated with a model can specify different values for any or all
configuration parameters. For more information, see About Configuration Sets on page 10-26. For
examples on how to use configuration sets, see:
Multiple Configuration Sets in a Model on page 10-3

Manage a Configuration Set on page 10-12
By default, a configuration set resides within a single model so that only that model can use it.
Alternatively, you can store a configuration set independently, so that other models can use it. A
configuration set that exists outside any model is a freestanding configuration set. Each model that uses
a freestanding configuration set defines a configuration reference that points to the freestanding
configuration set. A freestanding configuration set allows you to single-source a configuration set for
several models. For more information, see About Configuration References on page 10-29. For
examples on how to use configuration references, see:
Share a Configuration for Multiple Models on page 10-4

Share a Configuration Across Referenced Models on page 10-6
Manage a Configuration Reference on page 10-18
A model can include many different configuration sets. This capability is useful if you want to compare
the difference in simulation output after changing the values of several parameters. Attaching additional
configuration sets allows you to quickly switch the active configuration.
1 To create additional configuration sets in your model, in the Model Explorer, select your model node in
the Model Hierarchy pane and do one of the following:
Right-click the model node and select Configuration > Add Configuration.
Right-click an existing configuration set. In the context menu, select Copy.
2To import a previously saved configuration set, right-click the model node and select Configuration >
Import. In the Import Configuration From File dialog box, select a configuration file.
3To modify the newly added configuration set, in the Model Hierarchy pane, select the configuration
node. In the Contents pane, select a component, and then modify any parameters
whicharedisplayedintherightpane.
4To make the new configuration settheactiveconfiguration, inthe configuration set context menu, select
Activate. In the Model Hierarchy pane, the new configuration set name is now displayed as(Active).
5 To simulate your model using a different configuration set, switch the active configuration by
repeating step 4.
To share a configuration set between models, the configuration set must be a configuration set object in
the base workspace and you must create a configuration reference in your model to reference the
configuration set object. You can create configuration references in other models that also point to the
same configuration set object.
For example, first convert an existing configuration set in your model to a configuration reference:
2 In the Model Hierarchy pane, right-click the active configuration set to share.
3 In the configuration set context menu, select Convert to Configuration Reference, which opens a
dialog box. Alternatively, you can right-click the model node and select Configuration > Convert
Active Configuration to Reference.
4In the Convert Active Configuration to Reference dialog box, use the default configuration set object
name,configSetObj,ortypeaname.
5 Click OK, which creates a configuration reference in the model and a configuration set object in the
base workspace. The configuration reference points to the configuration set object, which has the same
values as the original active configuration set. The configuration reference name in the Model Hierarchy
is now marked as(Active).
6 To change the name of the configuration reference, select it in the Model Hierarchy, and in the right
pane, change the Name field.
To share the preceding configuration set, which is stored asconfigSetObj in the base workspace, create a
configuration reference in another model:
1 In the Model Hierarchy pane, right-click the model node.
2 In the context menu, select Configuration > Add Configuration Reference.
3 The Create Configuration Reference dialog box opens. Specify the name of the configuration set
object,configSetObj, in the base workspace.
4 To make the new configuration reference the active configuration, in the Model Hierarchy, right-click
the configuration reference. In the context menu, select Activate.
Both models now contain a configuration reference that points to the same configuration set object in the
base workspace. Before saving and closing your models, follow the instructions to Save a Referenced
Configuration Set on page 10-23. If you do not save the referenced configuration set from the base
workspace, when you reopen your model, the configuration reference is unresolved. To set up your
model to automatically load the configuration set object, see Callbacks for Customized Model
Behavior on page 4-55.
If you have a model reference hierarchy, you might want the top model and the referenced models to
share the same configuration set. You can use a configuration reference in each of the models to
reference the same configuration set object in the base workspace.
In the diagram, each model shown in the Model Dependency Viewer specifies the configuration
reference,my_configuration, as its active configuration set. my_configuration points to the freestanding
configuration set, Configuration. Therefore, the parameter values inConfiguration apply to all four
models. Any parameter change inConfiguration applies to all four models.
Convert Configuration Set to Configuration Reference

In the top model, you must converttheactiveconfigurationsettoa configuration reference:
1 Open thesldemo_mdlref_depgraph model and the Model Explorer.
2 In the Model Hierarchy pane, expand the top model, sldemo_mdlref_depgraph. In the list, right-
clickConfiguration (Active). In the context menu, select Convert to Configuration Reference.
3In the Configuration set name field, specify a name for the configuration set object, or use the default
name,configSetObj. This configuration set object is stored in the base workspace.
4 Optionally, you can save the configuration set to a MAT-file. Select Save configuration set to file.
This enables the File name parameter.
5 In the File name field, specify a name for the MAT-file.
6 Click OK.
The original configuration set is now stored as a configuration set object, configSetObj, in the base
workspace. The configuration set is also stored in a MAT-file,configuration_set.mat. The active
configuration for the top model is now a configuration reference. This configuration reference points to
the configuration set object in the base workspace.
Propagate a Configuration Reference
Now that the top model contains an active configuration reference, you can propagate this configuration
reference to all of the child models. Propagation creates a copy of the top model configuration reference
in each referenced model. For each referenced model, the configuration reference is now the active
configuration. The configuration references point to the configuration set
object,configSetObj,inthebaseworkspace.
1 In the Model Explorer, in the Model Hierarchy pane, expand the sldemo_mdlref_depgraph node.
2Right-click the active configuration

reference, Reference (Active).Inthe context menu, select Propagate to Referenced Models.
3 In the Configuration Reference Propagation dialog box, select the check box for each referenced
model. In this example, they are already selected.
4Verify that your current folder is a writable folder. The propagation mechanism saves the original
configuration parameters for each referenced model so that you can undo the propagation. Click
Propagate.
5In the Propagation Confirmation dialog box, click OK.

6In the Configuration Reference Propagation dialog box, the Propagation Report is updated and the
Status for each referenced model is marked as Converted.
Undo a Configuration Reference Propagation
After propagating a configuration reference from a top model to the referenced models, you can undo
the propagation for all referenced models by clicking Restore All. If you want to undo the propagation
for individual referenced models, in the Undo/Redo column, click the Undo button. The Propagation
Report is updated and the Status for the referenced model is set toRestored.
In this section...
CreateaConfigurationSetintheBaseWorkspace
OpenaConfigurationSetintheConfiguration Parameters Dialog Box

Copy, Delete, and Move a Configuration Set Save a Configuration Set

2 In the Model Hierarchy pane, select the model name.
3 You can create a new configuration set in any of the following ways:
From the Add menu, select Configuration.
On the toolbar, click the Add Configuration button
.
In the Model Hierarchy pane, right-click an existingconfigurationset and copy and paste the
configuration set.
Create a Configuration Set in the Base Workspace

2 In the Model Hierarchy pane, select Base Workspace.
3 You can create a new configuration set object in the following ways:
From the Add menu, select Configuration
In the toolbar, click the Add Configuration button
4 The configuration set object appears in the Contents pane, with the default name,ConfigSet.
OpenaConfigurationSetintheConfiguration Parameters Dialog Box
In the Model Explorer, to open the Configuration Parameters dialog box for a configuration set, right-
click the configuration sets node to display the context menu, then select Open. You can open the
Configuration Parameters dialog box for any configuration set, whether or not it is active.
The title bar of the dialog box indicates whether the configuration set is active or inactive.
Note Every configuration set has its own Configuration Parameters dialog box. As you change the state
of a configuration set, the title bar of the dialog box changes to reflect the state.
Only one configuration set associated with a model is active at any given time. The active set determines
the current values of the model parameters. You can change the active or inactive set at any time (except
when executing the model). In this way, you can quickly reconfigure a model for different purposes, for
example, testing and production, or apply standard configuration settings to new models.
To activate a configuration set, right-click the configuration set node to display the context menu, then
select Activate.
To set the value of a parameter in a configuration set, in the Model Explorer:

1 In the Model Hierarchy, select the configuration set node.
2 In the Contents pane, select the component from where the parameter resides.
3 In the Dialog pane, edit the parameter value.
Copy, Delete, and Move a Configuration Set
You can use edit commands on the Model Explorer Edit or context menus or object drag-and-drop
operations to delete, copy, and move configuration sets among models displayed in the Model
Hierarchy pane.
For example, to copy a configuration set from one model to another:

1 In the Model Hierarchy pane, right-click the configuration set node that you want to copy.
2 Select Copy in the configuration set context menu.
3 Right-click the model node in which you want to create the copy.
4 Select Paste from the model context menu.
To copy the configuration set using object drag-and-drop, hold down the right
mousebuttonanddragtheconfigurationsetnodetothenodeofthemodelin which you want to create the copy.
To move a configuration set from one model to another using drag-and-drop, hold the left mouse button
down and drag the configuration set node to the node of the destination model.
Note You cannot move or delete an active configuration set from a model.
Save a Configuration Set
You can save the settings of configuration sets as MATLAB functions or scripts. Using the MATLAB
function or script, you can share and archive model configuration sets. You can also compare the settings
in different configuration sets by comparing the MATLAB functions or scripts of the configuration sets.
To save an active or inactive configuration set from the Model Explorer:

1 Open the model.
3 Save the configuration set:
a In the Model Hierarchy pane:
Right-click the model node and select Configuration > Export Active Configuration Set.
Right-click a configuration set and select Export.
Select the model. In the Contents pane, right-click a configuration set and select Export.
b IntheExportConfigurationSettoFiledialogbox,specifythenameof thefileandthefiletype. Ifyouspecifya.m

extension, the file contains a function that creates a configuration set object. If you specify a.mat
extension, the file contains a configuration set object.
Note Donotspecifythenameofthefiletobethesameasamodelname. Ifthefileandmodelhavethesamename,

the software cannot determine which file contains the configuration set object when loading the file.
c Click Save. The Simulink software saves the configuration set.
You can load configuration sets that you previously saved as MATLAB functions or scripts.
To load a configuration set from the Model Explorer:
1 Open the model.
3 In the Model Hierarchy pane, right-click the model and select Configuration > Import.
4 In the Import Configuration Set From File dialog box, select the.m file that contains the function to
create the configuration set object, or the.mat file that contains the configuration set object.
5 Click Open. The Simulink software loads the configuration set.

Note If you load a configuration set object that contains an invalid custom target, the software sets the
System target file parameter toert.tlc.
6 Optionally, activate the configuration set. For more information, see Activate a Configuration Set on
page 10-13.
To copy a configuration set component from one configuration set to another:

1 Select the component in the Model Explorer Contents pane.
2 From either the Model Explorer Edit menu or the component context menu, select Copy.
3 Select the configuration set into which you want to copy the component.
4 From either the Model Explorer Edit menu or the component context menu, select Paste.
Note The copy replaces the component of the same name in the destination configuration set. For
example, if you copy the Solver component of configuration set A and paste it into configuration set B,
the copy replaces the existing Solver component in B.
In this section...
Create and Attach a Configuration Reference Resolve a Configuration Reference
Manage Configuration Reference Across Referenced Models Change Parameter Values in a
Referenced Configuration Set

Why is the Build Button Not Available for a Configuration Reference?
Create and Attach a Configuration Reference
To use a configuration reference, it must point to freestanding configuration set. Create a freestanding
configuration set before creating a configuration reference, see Create a Configuration Set in the Base
Workspace on page 10-12.
To create a configuration reference:

1 In the Model Explorer, in the Model Hierarchy pane, select the model.
2 Click the Add Reference tool
or select Add > Configuration Reference. The Create Configuration Reference dialog box opens.
3 Specify the Configuration set name of the configuration set object in the base workspace to be
referenced.
4Click OK. If you chose to create a configuration reference without first creating a configuration set
object, a dialog box opens asking if you would like to continue. If you choose:
Yes, an unresolved configuration reference is created. For more information, see Unresolved
Configuration References on page 10-30. Follow the instructions inResolve a Configuration
Reference on page 10-19.
No, then the configuration reference is not created. Follow the instructions inCreate a Configuration
Set in the Base Workspace on page 10-12, and then return to step 1 above.
5 A new configuration reference appears in the Model Hierarchy under the selected model. The default
name of the new reference isReference.
Resolve a Configuration Reference
An unresolved configuration reference is a configuration reference that is not pointing to a valid

configuration set object.
To resolve a configuration reference:
1In the Model Hierarchy pane, select the unresolved configuration reference or right-click the
configuration reference, and select Open from the context menu.
The Configuration Reference dialog box opens in the Dialog pane or a separate window.
2Specify the Referenced configuration set to be a configuration set object already in the base
workspace. If one does not exist, see Create a Configuration Set in the Base Workspace on page
10-12.
Tip Do not specify the name of a configuration reference. If you nest a configuration reference, an error
occurs.
3 Click OK or Apply.
If you specified a Referenced configuration that exists in the base workspace, the Is Resolved field in
the dialog box changes toyes.
After you create a configuration reference and attach it to a model, you can activate it so that it is the
active configuration.
In the GUI, from the context menu of the configuration reference, select Activate.
From the API, executesetActiveConfigSet, specifying the configuration reference as the second
argument.
When a configuration reference is active, the Is Active field of the Configuration Reference dialog box
changes toyes. Also, the Model Explorer shows the name of the reference with the suffix(Active).
The freestanding configuration set of the active reference now provides the configuration parameters for
the model.
Manage Configuration Reference Across Referenced Models
In a model hierarchy, you can share a configuration reference across referenced models. Using the
Configuration Reference Propagation dialog box, you can propagate a configuration reference of a top
model to an individual referenced model or to all referenced models in the model hierarchy. The dialog
box provides:
A list of referenced models in the top model.

The ability to select only specific referenced models for propagation.
After propagation, the status for the converted configuration for each referenced model.
A view of the changed parameters after the propagation.
The ability to undo the configuration reference and restore the previous configuration settings for a
referenced model.
To open the dialog box, in the Model Explorer, in the model hierarchy pane, right-click the configuration
reference node of a model. In the context menu, selectPropagate to Referenced Models. For an example,
see Share a Configuration Across Referenced Models on page 10-6.
Change Parameter Values in a Referenced Configuration Set
To obtain a referenced configuration set:
1 In the Model Hierarchy pane, select the configuration reference, or right-click the configuration
reference, and select Open from the context menu.
The Configuration Reference dialog box appears in the Dialog pane or in a separate window.
2To the right of the Referenced configuration field, click Open.The Configuration Parameters dialog
box opens. You can now change and apply parametervaluesasyouwould for any configuration set.
If your model uses a configuration reference to specify the model configuration, before closing your
model, you need to save the referenced configuration set to a MAT-file or MATLAB script.
1 In the Model Explorer, in the Model Hierarchy, select Base Workspace.
2 In the Contents pane, right-click the name of the referenced configuration set object.
3 From the context menu, select Export Selected.
4 Specify the filename for saving the configuration set as either a MAT-file or a MATLAB script.
Tip When you reopen the model you must load the saved configuration set, otherwise, the configuration
reference is unresolved. To set up your model to automatically load the configuration set object, see
Callbacks for Customized Model Behavior on page 4-55.
If your model uses a configuration reference to specify the model configuration, you need to load the
referenced configuration set from a MAT-file or MATLAB script to the base workspace.
1In the Model Explorer, in the Model Hierarchy, right-click Base Workspace.
2From the context menu, select Import.
3Specify the filename for the saved configuration set and select OK. The configuration set object
appears in the base workspace.
Tip When you reopen the model you must load the saved configuration set, otherwise, the configuration
reference is unresolved. To set up your model to automatically load the configuration set object, see
Callbacks for Customized Model Behavior on page 4-55.
Why is the Build Button Not Available for a Configuration Reference?
The Code Generation pane of the Configuration Parameters dialog box contains a Build button. Its
availability depends on whether the configuration set displayed by the dialog box resides in a model or
is a freestanding configuration set.
When the pane displays a configuration set stored in a model, the Build button is available. Click it to
generate and compile code for the model.
When the pane displays a freestanding configuration set, the Build button is unavailable. The
configuration set does not know which (if any) models link to it.
To provide the same capabilities whether a configuration set resides in a model or is freestanding, the
Configuration Reference dialog box contains a Build button. This button has the same capability as its
equivalent in the Configuration Parameters dialog box. It operates on the model that contains the
configuration reference.
In this section...
What Is a Freestanding Configuration Set? Model Configuration Preferences
A configuration set comprises groups of related parameters called components. Every configuration set
includes the following components:
Solver
Data Import/Export
Optimization
Diagnostics
Hardware Implementation
Model Referencing
Simulation Target
Some MathWorks products that work with Simulink, such as Simulink Coder, define additional
components. If such a product is installed on your system, the configuration set also contains the
components that the product defines.
When you select any model configuration, the Model Configuration dialog appears in the Model
Explorer Dialog pane. In this location, you can edit the name and description of your configuration.
What Is a Freestanding Configuration Set?
A freestanding configuration set is a configuration set object, Simulink.ConfigSet, stored in the base
workspace. To use a freestanding configuration set as the configuration for a model, you must create a
configuration reference in the model that references it. You can create a freestanding configuration set in
the base workspace in these ways:
Create a new configuration set object.

Copy a configuration set that resides within a model to the base workspace.
Load a configuration set from a MAT-file.
You can store any number of configuration sets in the base workspace by assigning each set to a
different MATLAB variable.
Note Although you can store a configuration set in a model and point to it with a base workspace
variable, such a configuration set is not freestanding. Using it in a configuration reference causes an
error.
Model Configuration Preferences
Model Configuration Preferences are the preferred configuration for new models. You can change the
preferred configuration by editing the settings in the Model Explorer.
1 Select View > Show Configuration Preferences to display the Configuration Preferences node in
the expanded Simulink Root node.
2 Under the Simulink Root node, select Configuration Preferences.The Model Configuration
Preferences dialog box opens in the Dialog pane.
3 In the Contents pane, select components and change any parameter values.
In this section...
Configuration References for Models with Older Simulation Target Settings
A configuration reference in a model is a reference to a configuration set objectinthebaseworkspace.

Amodelthathasaconfiguration reference that points to a freestanding configuration set uses that
configuration set when configuration reference is active. The model then has the same configuration
parameters as if the referenced configuration set resides directly in the model.
You can attach any number of configuration references to a model. Each reference must have a unique
name. For more information, see Why Use Configuration References? on page 10-29. For an example
on how to use configuration references, see Share a Configuration for Multiple Models on page 10-4
or Create and Attach a Configuration Reference on page 10-18.
Tip Save or export the configuration set object. Otherwise, when you reopen your model the
configuration reference is unresolved. To set up your model to automatically load the configuration set
object, see Callbacks for Customized Model Behavior on page 4-55.
You can use configuration references and freestanding configuration sets to:
Assign the same configuration set to any number of models
Each model that uses a given configuration set contains a configuration reference that points to a
MATLAB variable. The value of that variable is a freestanding configuration set. All the models share
that configuration set. Changing the value of any parameter in the set changes it for every model that
uses the set. Use this feature to reconfigure many referenced models quickly and ensure consistent
configuration of parent models and referenced models.
Replace the configuration sets of any number of models without changing the model files
When multiple models use configuration references to access a freestanding configuration set, assigning
a different set to the MATLAB variable assigns that set to all models. Use this feature to maintain a
library of configuration sets and assign them to any number of models in a single operation.
Use different configuration sets for a referenced model used in different contexts without
changing the model file
A referenced model that uses different configuration sets in different contexts contains a configuration
reference that specifies the referenced model configuration set as a variable. When you call an instance
of the referenced model, Simulink software assigns that variable a freestanding configuration set for the
current context.
When a configuration reference does not reference a valid configuration set, the Is Resolved field of the
Configuration Reference dialog box has the value no. If you activate an unresolved configuration
reference, no warning or error occurs. However, an unresolved configuration reference that is active
provides no configuration parameter values to the model. Therefore:
Fields that display values known only by accessing a configuration parameter, like Stop Time in the
model window, are blank.
Trying to build the model, simulate it, generate code for it, or otherwise require it to access
configuration parameter values, causes an error. For more information, see Resolve a Configuration
Reference on page 10-19.
You cannot nest configuration references. Only one level of indirection is available, so a configuration
reference cannot link to another configuration reference. Each reference must specify a freestanding
configuration set.
If you replace the base workspace variable and configuration set that configuration references use,
executerefresh for each reference that usesthereplacedvariableandset. SeeUserefresh When Replacing a
Referenced Configuration Set on page 10-41.
If you activate a configuration reference when using a custom target, the ActivateCallback function
does not trigger to notify the corresponding freestanding configuration set. Likewise, if a freestanding
configuration set switches from one target to another, theActivateCallback function does not trigger to
notify the new target. This behavior occurs, even if an active configuration reference points to that
target. For more information aboutActivateCallback functions, see rtwgensettings Structure in the
Simulink Coder documentation.
Configuration References for Models with Older Simulation Target Settings
Suppose that you have a nonlibrary model that contains one of these blocks:
MATLAB Function
Stateflow chart
Truth Table
Attribute Function
In R2008a and earlier, this type of nonlibrary model does not store simulation target (orsfun) settings in
the configuration parameters. Instead, the model stores the settings outside any configuration set.
When you load this older type of model, the simulation target settings migrate to parameters in the
active configuration set.
Iftheactiveconfigurationsetresides internally with the model, the migration happens automatically.

If the model uses an active configuration reference to point to a configuration set in the base
workspace, the migration process is different.
The following sections describe the two types of migration for nonlibrary models that use an active
configuration reference.
Default Migration Process That Disables the Configuration Reference

Becausemultiplemodelscanshareaconfigurationsetinthebaseworkspace, loading a nonlibrary model
cannot automatically change any parameter values in that configuration set. By default, these actions
occur during loading of a model to ensure that simulation results are the same, no matter which version
of the software that you use:
A copy of the configuration set in the base workspace attaches to the model.
The simulation target settings migrate to the corresponding parameters in this new configuration set.
The new configuration set becomes active.
The old configuration reference becomes inactive.
A warning message appears in the MATLAB Command Window to describe those actions. Although
this process ensures consistent simulation results for the model, it disables the configuration reference
that links to the configuration set in the base workspace.
Model Configuration Command Line Interface
In this section...
Overview
Load and Activate a Configuration Set at the Command Line
Save a Configuration Set at the Command Line

Create a Freestanding Configuration Set at the Command Line
Create and Attach a Configuration Reference at the Command Line
Attach a Configuration Reference to Multiple Models at the Command Line
Get Values from a Referenced Configuration Set

Change Values in a Referenced Configuration Set
Userefresh When Replacing a Referenced Configuration Set
Overview
An application programming interface (API) lets you create and manipulate configuration sets at the
command line or in a script. The API includes the Simulink.ConfigSet andSimulink.ConfigSetRef
classes and the following functions:
attachConfigSet
attachConfigSetCopy
detachConfigSet
getConfigSet
getConfigSets
setActiveConfigSet
getActiveConfigSet
openDialog
closeDialog
Simulink.BlockDiagram.saveActiveConfigSet
Simulink.BlockDiagram.loadActiveConfigSet
These functions, along with the methods and properties of Simulink.ConfigSet class, allow you to create
a script to:
Create and modify configuration sets.

Attach configuration sets to a model.
Set the active configuration set for a model.
Open and close configuration sets.
Detach configurationsetsfromamodel.
Save configuration sets.
Load configuration sets.
For examples using the preceding functions and theSimulink.ConfigSet class, see the function and class
reference pages.
Load and Activate a Configuration Set at the Command Line
To load a configuration set from a MATLAB function or script:

1 Use thegetActiveConfigSet orgetConfigSet function to get a handle to the configuration set that you
want to update.
2 Call the MATLAB function or execute the MATLAB script to load the saved configuration set.
3Optionally, use theattachConfigSet function to attach the configuration set to the model. To avoid
configuration set naming conflicts, set allowRename totrue.
4Optionally, use thesetActiveConfigSet function to activate the configuration set.

Alternatively, to load a configuration set at the command line and make it the active configuration set:
1 Open the model.
2 Use theSimulink.BlockDiagram.loadActiveConfigSet function to load the configuration set and make
it active.
Note Ifyouloadaconfigurationsetwiththesamenameasthe:
Active configuration set, the software overwrites the active configuration set.
Inactive configuration set that is associated with the model, the software detaches the inactive
configuration from the model.
Save a Configuration Set at the Command Line
To save an active or inactive configuration set as a MATLAB function or script:

1 Use thegetActiveConfigSet orgetConfigSet function to get a handle to the configuration set.
2 Use thesaveAs method of theSimulink.Configset class to save the configuration set as a function or
script.
Alternatively, to save the active configuration set:
1 Open the model.
2 Use theSimulink.BlockDiagram.saveActiveConfigSet function to save the active configuration set.
Create a Freestanding Configuration Set at the Command Line
Copy a Configuration Set Stored in a Model

Create a freestanding configuration settobereferencedbyaconfiguration reference in several models. You
must copy any configuration set obtained from an existing model, otherwise, cset refers to the existing
configuration set stored in the model, rather than a new freestanding configuration set in the base
workspace. For example, use one of the following:
cset = copy (getActiveConfigSet(model))

cset = copy (getConfigSet(model, ConfigSetName))
model is any open model, and ConfigSetNameisthenameofanyconfiguration set attached to the model.
Read a Configuration Set from a MAT-File

To use a freestanding configuration set across multiple MATLAB sessions, you can save it to a MAT-
file. To create the MAT-file, you first copy the configuration set to a base workspace variable, then save
the variable to the MAT-file:
save (workfolder/ConfigSetName.mat, cset)
workfolder is a working folder, ConfigSetName.matistheMAT-filename, and

csetisabaseworkspacevariablewhosevalueistheconfigurationset to save. When you later reopen your
model, you can reload the configuration set into the variable:
load (workfolder/ConfigSetName.mat)
To execute code that reads configuration sets from MAT-files, use one of these techniques:
The preload function of a top model

The MATLAB startup script
Interactive entry ofload statements
Create and Attach a Configuration Reference at the Command Line
To create and populate a configuration reference, Simulink.ConfigSetRef, using the API:

1 Create the reference:
cref = Simulink.ConfigSetRef
2 Change the default name if desired:
cref.Name = 'ConfigSetRefName'
3 Specify the referenced configuration set:
cref.WSVarName = 'cset'
Tip Do not specify the name of a configuration reference. If you nest a configuration reference, an error
occurs.
4 Attach the reference to a model:
attachConfigSet(model, cref, true)
The third argument is optional and authorizes renaming to avoid a name conflict.
Using a configuration reference with an invalid configuration set, WSVarName, generates an error and is
called an unresolved configuration reference. The GUI equivalent ofWSVarName is Referenced
configuration.Youcanlater use the API or GUI to provide the name of a freestanding configuration set.
For more information, see Unresolved Configuration References on
Attach a Configuration ReferencetoMultipleModels at the Command Line
After you create a configuration reference and attach it to a model, you can attach copies of the
reference to any other models. Each model has its own copy of any configuration reference attached to
it, just as each model has its own copy of any attached configuration set.
IfyouusetheGUI,attachinganexisting configuration reference to another model automatically attaches a

distinct copy to the model. If necessary to prevent name conflict, the GUI adds or increments a digit at
the end ofthenameofthecopiedreference. IfyouusetheAPI,besuretocopythe configuration reference
explicitly before attaching it, with statements like:
cref = copy (getConfigSet(model, ConfigSetRefName)) attachConfigSet (model, cref, true)
If you omit the copy operation, cref becomes a handle to the original configuration reference, rather than
a copy of the reference. Any attempt to use cref causes an error. If you omit the argumenttrue
toattachConfigSet, the operation fails if a name conflict exists.
The following example shows code for obtaining a freestanding configuration set and attaching
references to it from two models. After the code executes, one of the models contains an internal
configuration set and a configuration reference that points to a freestanding copy of that set. If the
internal copy is an extra copy, you can remove it withdetachConfigSet,asshowninthe last line of the
example.
open_system('model1')
% Get handle to local cset
cset = getConfigSet('model1', 'Configuration')
% Create freestanding copy; original remains in model cset1 = copy(cset)
% In the original model, create a configuration % reference to the cset copy

cref1 = Simulink.ConfigSetRef
cref1.WSVarName = 'cset1'
% Attach the configuration reference to the model attachConfigSet('model1', cref1, true)
% In a second model, create a configuration % reference to the same cset

open_system('model2')
% Rename if name conflict occurs
attachConfigSetCopy('model2', cref1, true)
% Delete original cset from first model detachConfigSet('model1', 'Configuration')
Get Values from a Referenced Configuration Set
You can use get_param on a configuration reference to obtain parameter values from the linked
configuration set, as if the reference object were the configuration set itself. Simulink software retrieves
the referenced configuration set and performs the indicatedget_param on it.
For example, if configuration reference cref links to configuration set cset, the following operations give
identical results:
get_param (cset, 'StopTime') get_param (cref, 'StopTime')
Change Values in a Referenced Configuration Set
By operating on only a configuration reference, you cannot change the referenced configuration set
parameter values. If you execute:
set_param (cset, 'StopTime', '300')
set_param (cref, 'StopTime', '300') % ILLEGAL
the first operation succeeds, but the second causes an error. Instead, you must obtain the configuration
set itself and change it directly, using the GUI or the API.
To obtain a referenced configuration set using the API: 1 Follow the instructions in Obtain a
Configuration Reference Handle on
2 Obtain the configuration set cset from the configuration reference cref:
cset = cref.getRefConfigSet
You can now useset_param on cset to change parameter values. For example:
set_param (cset, 'StopTime', '300')
Tip If you want to change parameter values through the GUI, execute:
cset.openDialog
The Configuration Parameters dialog box opens on the specified configuration set.
Most functions and methods that operate on a configuration reference take a handle to the reference.
When you create a configuration reference:
cref = Simulink.ConfigSetRef
the variable cref contains a handle to the reference. If you do not already have a handle, you can obtain
one by executing:
cref = getConfigSet(model,'ConfigSetRefName')
ConfigSetRefName is the name of the configuration reference as it appears in the Model Explorer, for
example,Reference. Youspecifythisnamebysetting the Name field in the Configuration Reference dialog
box or executing:
cref.Name = 'ConfigSetRefName'
The technique for obtaining a configuration reference handle is the same technique you use to obtain a
configuration set handle. Wherever the same operation applies to both configuration sets and
configuration references, applicable functions and methods overload to perform correctly with either
class.
Use refresh When Replacing a Referenced Configuration Set
You can replace the base workspace variable and configuration set that a configuration reference uses.
However, the pointer from the configuration reference to the configuration set becomes invalid. To avoid
this situation, execute:
cref.refresh
cref is the configuration reference. If you do not execute refresh, the configuration reference continues
tousethepreviousinstanceofthebase workspace variable and its configuration set. This example illustrates
the problem.
% Create a new configuration set cset1 = Simulink.ConfigSet;

% Set a non-default stop time set_param (cset1, 'StopTime', '500')
% Create a new configuration reference cref1 = Simulink.ConfigSetRef;
% Resolve the configuration reference to the configuration set cref1.WsVarName = 'cset1';
% Attach the configuration reference to an untitled model attachConfigSet('untitled', cref1, true)
% Set the active configuration set to the reference setActiveConfigSet('untitled','Reference')
% Replace config set in the base workspace cset1 = Simulink.ConfigSet;
% Call to refresh is commented out! % cref1.refresh;
% Set a different stop time
set_param (cset1, 'StopTime', '75')
If you simulate the model, the simulation stops at 500, not 75. Calling cref1.refresh as shown prevents
the problem.
Configuring Models for Targets with Multicore
Processors
Design Considerations
Analyze Baseline
Customize Concurrent Execution Settings
Build and Download to a Multicore Target
In this section...
About Configuring Models for Concurrent Execution Supported Targets
Helpful Terms
About Configuring Models for Concurrent Execution
Configuring your model for concurrent execution in the Simulink environment enables you to capture
and simulate the effects of deploying your design to a multicore system. A model that is configured for
concurrent execution gives you control over how a design should execute on a multicore target. It allows
thedesigntobemappedintoconcurrentlyexecutingtasks. Subsequently, the Simulink environment enables
the simulation of the mapped design by identifying data transfer points and by simulating the mapped
design in conjunction with data transfer latencies. You can deploy the design to a multicore system using
Simulink Coder, Embedded Coder, and xPC Target software.
You can use simulation results to identify whether a mapping scheme is suitable with respect to the
functional characteristics of the design. You can also explore alternate partitioning schemes using a
mapping interface. In addition, you can use profiling results on the deployed design to validate if the
mapping scheme is efficiently using the multicore system.
Create a new model configuration or extend existing configurations for concurrent execution.
Use the Model block to define potential opportunities for concurrency in your design.
Set up and configure concurrent on-target tasks using a task editing interface.
Use either the GUI or command-line interface to iteratively map design partitions (based on Model
blocks) to tasks and find optimal concurrent execution scenarios.
Generate code that uses threading APIs on Windows, Linux, or xPC Target platforms for on-target
execution.
Supported Targets
You can build and download concurrent execution models for the following targets using system target
files:
Linux, Windows, and Mac OS usingert.tlc and grt.tlc.

xPC Target usingxpctarget.tlc andxpctargetert.tlc.
Linux and Windows usingidelink_ert.tlc andidelink_grt.tlc.
Embedded Linux and VxWorks usingidelink_ert.tlc and idelink_grt.tlc.

Note Deploying to embedded Linux and VxWorks targets requires the Embedded Coder product.
You cannot build and download a model, configured for concurrent execution, for field-programmable
gate arrays (FPGAs) and programmable logic controllers (PLCs). For FPGA optimization and hardware
utilization techniques, see the Streaming, Resource Sharing, and Delay Balancing chapter of the HDL
Coder Users Guide.
Helpful Terms
Task Object that corresponds to a thread of execution on a target. From within the Simulink
environment, you can specify tasks, configure their properties, and map Model blocks to them.
Task configuration Configuration properties that apply to the set of tasks set up for your multicore
system.
Trigger Abstraction of operating system timers, signals, interrupts, and system events.
Aperiodic trigger Event trigger that has no inherent periodicity, such as an interrupt. When multiple
triggers coexist, the software assumes that they are asynchronous to each other.
Periodic triggersPeriodiceventtriggersuchasanoperatingsystem trigger.
To build and download your model, you must have Simulink Coder software installed.
To build and download your model to an xPC Target system, you must have xPC Target software
installed. You must also have a multicore target system supported by the xPC Target product.
Design Considerations
In this section...
Modeling for Concurrency Simulation Limitations
Modeling for Concurrency
A model configured for concurrent execution is defined as a model designed to execute concurrently on
a real-time multicore target. In this situation, different pieces of the model ultimately execute in
concurrent threads on the target environment. Modeling for concurrent execution allows the designer to
factor in the effect of the concurrent execution semantics within the model, to simulate and to provide
initial conditions for data transfer points.
Note The simulation itself does not require a multicore host. The current simulation engine uses only
one thread to simulate.
Modeling for concurrency is an iterative process. It ultimately deploys a model on a multicore target
environment while making the best use of the computational power provided by the multiple cores. To
support the iterative workflow, Simulink provides a mapping interface that allows you to map the
potential concurrency in the design to the actual concurrency available on the target. A model
configured for concurrent execution consists of three parts:
A model that has identified blocks for concurrent execution

A description of the available concurrency in terms of the number of tasks and their periodicities
A mapping that places the identified blocks in the model into actual tasks for concurrent execution
These parts constitute a mapped model. To manage mapped models, Simulink software provides:
Explicit control over task configuration and how blocks are mapped to tasks
Control over how data is communicated between tasks
Simulation of a mapped model that allows you to validate a desired functionality against the data
transfer requirements of a particular mapping
To validate if a particular mapping is an acceptable design, first validate that the mapped model
produces the desired simulation traces. Simulation results vary from mapping to mapping because each
mapping imposes communication (data transfer) requirements that might cause the Simulink software to
treat certain signal lines as delays for data transfer. Ultimately, however, you must evaluate the mapping
on the target, and profile the behavior to measure whether the mapping meets the computational
requirements and makes good use of the available computational power of the target platform. This
evaluation and profiling are beyond the scope of the software.
Identifying Opportunities for Concurrent Execution To use the software mapping interface, a model
must first specify opportunities for concurrency by identifying blocks for concurrent execution. Use
Model blocks (referenced models) to identify potential opportunities for concurrent execution. A Model
block defines a unit of functionality that the software can map for execution in one or more target tasks.
More precisely, you can map a multirate Model block that contains N rates to exactly N tasks, the
periodicity of which agree with the respective rates. You can map several Model blocks to the same task.
Map a Model block that contains continuous blocks to a task, the period of which agrees with the
fundamental sample time of the model. You can specify the fundamental sample time of the model in the
Fixed-step size (fundamental sample time) of the Solver pane in the Configuration Parameters dialog
box.
Because Model blocks must be used to express opportunities for concurrency, a design must consist
entirely of Model blocks. You can also use virtual connectivity blocks to organize the block diagram,
including:
Goto and From blocks

Ground and Terminator blocks
Inport and Outport blocks
Virtual subsystem blocks that contain permitted blocks
A model configured for concurrent execution reports an error diagnostic if any other blocks are detected.
Place all other blocks in one or more referenced models.
Also consider signal lines when designing for concurrent execution. Depending on the mapping, any
signal line can potentially be identified as a data transfer point. In particular, if the source port of a signal
originates in a block from one task and the destination port is to a block in another task, the Simulink
software identifies that signal as a data transfer point.
Algebraic Loops
An algebraic constraint or algebraic loop might impose tight coupling between tasks and can lead to
severe computational penalties. Therefore, a model configured for concurrent execution cannot contain
algebraic loops or algebraic constraints that originate from physical modeling in a referenced model.
This condition makes an algebraic loop fully contained in a task. However, the use of Model blocks
might lead to artificial algebraic loops. This condition might occur if Simulink cannot identify if a break
point is encapsulated within a referenced model. In such situations, use one of the following methods to
remove artificial algebraic loops:
In the referenced model Configuration Execution dialog box, select Model Referencing > Minimize
algebraic loop occurrences.
Insert a Memory or Unit Delay block as the first block at the relevant input port of the referenced
model.
Additionally, if the model is configured for the Embedded Coder target (ert.tlc), in the Configuration
Parameters dialog box, clear the Code Generation > Interface > Single output/update function check
box. This last operation prevents optimizations that can lead to artificial algebraic loops.
Simulation Limitations
When modeling for concurrent execution, configure the model to use the fixed-step solver.
Do not use the following modes of simulation for models in the concurrent execution environment:
External mode
Logging to MAT-files
If you are simulating your model using Rapid Accelerator mode, the top-level model cannot contain a
root level Inport block that outputs function calls.
In the Configuration Parameters dialog box, set the Diagnostics > Sample Time > Multitask
conditionally executed subsystem and Diagnostics > Data Validity > Multitask data store
parameters toerror.
In addition, for all Rate Transition blocks within the Model blocks:
Select the Ensure data integrity during data transfer check box.
Clear the Ensure deterministic data transfer (maximum delay) check box.
You can model for concurrent execution using the following general workflow. These steps assume that
you have a model that meets the modeling guidelines in Design Considerations on page 11-5.
1 Optionally, save your original model to a temporary folder.

2 Configure your model for concurrent execution.
3 Perform baseline analysis of your model for concurrent execution.
4 Explicitly set configuration values in the concurrent execution configuration.
5 Simulate the model and evaluate the results
6 As necessary, refine the results.
7 Build and download the model to the multicore target and evaluate the results.
8 As necessary, refine the results.
You can use configuration references or configuration sets to configure a model for concurrent
execution.
If Your Model Has...
A single-level model, or if it has multiple descendants, such as reference models, and the descendants do
not share the same configuration settings.
A top-level model and multiple descendants, such as referenced models, all of which share the same
configuration settings.
Create...
A configuration set for a single model. For more information, see Creating a Concurrent Execution
Configuration Set on page 11-12.
A configuration reference object that can be shared between all models in the hierarchy. For more
information, see Creating and Propagating a Configuration Reference on page 11-13.
Creating a Concurrent Execution Configuration Set
You can create a concurrent execution configuration set from an existing configuration set, or create a
new configuration set:
1 In the Simulink model editor, select View > Model Explorer.
The Model Explorer window is displayed.
2 In the Model Explorer window:
To...
Preserve existing configuration settings for your model, convert an existing configuration set to a
concurrent execution configuration set.
Create new configuration settings, add a new concurrent execution configuration set.
Do...
Expand the node for the model. Under the model, right-click Configuration, then select Show
Concurrent Execution options.
Expand the node for the model. Right-click the model node and select Configuration > Add
Configuration for Concurrent Execution.
Activate the configuration set by right-clicking it and selecting Activate.
3 In the third column of the Model Explorer window, the Solver pane is updated to display an Allow
tasks to execute concurrently on target check box. Click the Configure Tasks button.
If you want to create a configuration reference, see Creating and Propagating a Configuration
Reference on page 11-13. Otherwise, to begin configuring the model for concurrent execution, see
Analyze Baseline on page 11-18.
Creating and Propagating a Configuration Reference
This topic assumes that you have an existing concurrent execution configuration. If you have not yet
created one, see Creating a Concurrent Execution Configuration Set on page 11-12.
For more information on configuration references, see About Configuration References on page
10-29. This topic describes one way to create and propagate a configuration reference.
1In the Simulink model editor, select View > Model Explorer.
The Model Explorer window is displayed. 2 In the Model Explorer window, expand the node for the
model and do one of the following:
To...
Preserve existing configuration settings for your model, convert an existing configuration set to a
concurrent execution configuration set.
Create new configuration settings, add a new concurrent execution configuration set.
Do...
Right-click and select

Configuration > Show
Concurrent Execution options.
Right-click and select

Configuration > Add
Configuration for Concurrent Execution.
3 Activate the configuration set by right-clicking it and selecting Activate.

4 Do one of the following:
Right-click the model name and select Configuration > Convert Active Configuration to Reference.
In the Model Hierarchy column, right-click Configuration > Convert to Configuration Reference.
A Convert Active Configuration to Reference dialog box is displayed.
5 Click OK to accept the default name

for the configuration reference.
The configuration is converted to a configuration reference.
6 To share the configuration reference with the other referenced models in the model hierarchy, activate
the configuration reference, then right-click it and select Configuration > Propagate to Referenced
Models.
A Propagate to Referenced Models dialog box is displayed.
7 Click Propagate to propagate the configuration reference.

A propagation confirmation dialog box is displayed.
8 Click OK to continue.
The hierarchy of each referenced model is updated with the configuration reference.
9 Click OK.
10 In the Model Explorer, in the left column, select the Reference (Active) node.
The right column changes to display the Configuration Parameters reference pane.
11 In the Configuration Parameters reference pane, click the Open button of the Referenced
configuration parameter.
The Configuration Parameters dialog box is displayed.
12 Navigate to the Solver node.
13 Click the Allow tasks to execute concurrently on target check box and click Configure Tasks
button.
The Open Task Editor dialog window is displayed.
Consider saving the configuration reference to MAT-file if you want to use it in future MATLAB
sessions. To save the configuration reference named configSetObj, enter the following command in the
MATLAB Command Window:
save configsetobj.mat configSetObj

To load the saved configuration reference into another MATLAB session, enter the following command
in the MATLAB Command Window:
load configsetobj.mat
To begin configuring the model for concurrent execution, see Analyze Baseline on page 11-18.
Analyze Baseline
Perform a baseline analysis of the model. This step helps you identify initial bottlenecks in the execution
of the original model. This topic assumes that you have configured your model for concurrent execution,
but have not yet defined tasks for your model (Configure Your Model on page 11-12). Simulink can
perform a sample time analysis of your model and create system tasks for you.
1In the Concurrent Execution dialog box, click the System tasks node.
2In the System tasks pane, click the Autogenerate tasks and mapping
button
Simulink updates the model block diagram and performs a sample time analysis. For each sample time,
the software creates a system task. When done, Simulink:
Creates one periodic system task (DiscreteN) for each periodic sample time in the model
Creates one aperiodic system trigger (AsynchronousN) for each function-call input in the model
Configures the block-to-task mapping so that each block maps to a system task based on sample time
analysis
Updatesthe System tasks pane with a table of the system tasks
3 Customize and save these new tasks.
To customize system tasks (for example, name them, make platform-specific changes, and so forth), or
save them, convert them to user tasks by right-clicking the system task or trigger and clicking Convert
to editable ....
Note Saving the model does not save autogenerated system tasks, only thoseconvertedtoeditable.
Besuretoconvertsystemtaskstoeditableif youwanttosavethem.
Analyze Baseline
The software performs a sample time analysis on the model as it currently exists.
If the software reports a diagnostic during the update phase that prevents the analysis from completing,
address the modeling issues before continuing.
The following is the automatic baseline analysis for the sldemo_concurrent_execution model. Notice
that system tasks
appear as empty task icons
in the dialog box.
When
the analysis is complete, decide on your next step.
To...
Explicitly configure how data is transferred to override the settings detected by automatic analysis.
Simulate the model.

Go to...
Customize Concurrent Execution Settings on page 11-21.
Interpret Simulation Results on page 11-29.
Customize Concurrent Execution Settings
After you set perform sample time analysis and create and assign system tasks, you might want to fine-
tune simulation results by performing operations such as explicitly creating a different number of tasks
or setting data transfer parameters.
Note If you do not want to customize concurrent execution settings, in the Concurrent Execution pane
clear the Enable explicit model partitioning for concurrent behavior check box. Clearing this check
box allows the model to use rate-based tasks and ignores task-to-block mappings.
Configuring Data Transfer Communications
Use the Data Transfer Options pane to define communications between tasks.
Data Transfer Options
Data Transfer Type Ensure data integrity only.
Simulation
Data transfer is simulated using a one-step delay.
Ensure deterministic transfer (maximum delay).
Ensure deterministic transfer (minimum delay).

Data transfer is
simulated using a one-step delay.
Data transfer occurs within the same step.

Deployment
Simulink Coder ensures data integrity during data transfer. Data is transferred as soon as possible.
Simulink Coder
ensures data transfer is identical with
simulation.
For continuous signals, the Simulink software uses extrapolation methods to compensate for numerical
errors that were introduced due to delays and discontinuities in data transfer.
For signals that are configured forEnsure Data Integrity Only and Ensure deterministic transfer
(maximum delay) data transfers, you might need to provide an initial condition to avoid numerical
errors. You can specify this initial condition in the Data Transfer tab of the Signal Properties dialog
box. To access this dialog box, right-click the signal line and select Properties from the context menu.
A dialog box like the following is displayed.
From
1
the Data Transfer Options on page 11-21 table, determine how you want your tasks to communicate.
2 In the Concurrent Execution dialog box, select Data Transfer defaults and apply the settings from step
1.
3 Apply your changes.
Configuring Periodic Tasks
If you want to explore the effects of increasing the concurrency on your model execution, you can create
additional periodic tasks in your model.
1 In the Concurrent Execution dialog box, right-click on the Periodic node and select Add task.
A task node appears in the Configuration Execution hierarchy.
2 Select the task node and enter a name and period for the task, then click Apply.
The task node is renamed to the name you enter.
3 Optionally, specify a color for the task. The color illustrates the block-to-task mapping. If you do not
assign a color, Simulink chooses a default color. If you enable sample time colors for your model, the
software honors the setting.
4 Click Apply as necessary.
When the periodic tasks are complete, configure the aperiodic (interrupt) tasks as necessary. If you do
not need aperiodic tasks, continue to Map Blocks to Tasks Incrementally on page 11-26.
Configuring Aperiodic Triggers and Tasks
1To create an aperiodic trigger, in the Concurrent Execution dialog box, right-click the Concurrent
Execution node and click the Add aperiodic trigger icon.
Anodenamed InterruptN appears in the configuration tree hierarchy.
2 Select Interrupt.
This node represents an aperiodic trigger for your system.
3 Specify the name of the trigger and configure the aperiodic trigger source. Depending on your
deployment target, choose eitherPosix Signal (Linux/VxWorks 6.x) orEvent (Windows).ForPOSIX
signals, specify the signal number to use for delivering the aperiodic event. For Windows events, specify
the name of the event.
4 Click
Apply.
Thesoftwareservicesaperiodictriggers as soon as the system can respond to the trigger. If you want to
process the trigger response using a task:
1 Right-click the Interrupt node and select Add task.
A new task node appears under the Interrupt node.
2 Specify the name of the new task node.
3 Optionally, specify a color for the task. The color illustrates the block-to-task mapping. If you do not
assign a color, Simulink chooses a default color.
4 Click Apply.
Youcandeletetasks(bothperiodicandaperiodic)aswellastriggersby right-clicking them in the pane and
selecting Delete.
When the aperiodic tasks are complete, continue to Map Blocks to Tasks Incrementally on page 11-26.
Map Blocks to Tasks Incrementally
After you simulate and evaluate a model that has baseline analysis settings, you can continue to add new
Model blocks, change the model, or redo the block-to-task mapping. You do this in one of the following
ways:
Use system tasks to incrementally map blocks to tasks. For more information, see Map
Incrementally on page 11-26. You can partially map blocks to tasks, assigning tasks only for the blocks
you are interested in, then use system tasks to complete the mapping so that you do not need to manually
map all blocks to all tasks.
Manually map blocks to tasks. For more information, see Mapping Blocks to Tasks Manually on
page 11-27. You can manually map tasks for the blocks you are interested in, then use system tasks to
incrementally map blocks to tasks to complete the mapping.
Map Incrementally
1 In the Concurrent Execution dialog box, click the Tasks and Mapping node.
The Map blocks to tasks pane appears. If you added a new Model block to your model, the new block
appears in the table with a select task entry under it.
2 If you changed the model by adding or removing blocks and have not yet added new tasks and triggers
for them, perform a sample time analysis, as described in Analyze Baseline on page 11-18.
The software performs a sample time analysis on the model as it currently exists.
3 Save the model. When the mapping is complete, simulate the model again (see Interpret Simulation
Results on page 11-29).
Mapping Blocks to Tasks Manually
1 In the Concurrent Execution dialog box, click the Tasks and Mapping node.
The Map blocks to tasks pane appears. If you added a new Model block to your model, the new block
appears in the table with a select task entry under it.
2 If you want to add a new task to a block, in the Name column, right-click a task under the block and
select Add new entry.
3To assign a task for the entry, click the box in the Name column and select a task from the list. For
example:
The block-to-task mapping icon appears on the top-left corner of the Model block. If a Model block is
assigned to multiple tasks, multiple task icons are displayed in the top-left corner. For example:
Click Apply.
4
When the mapping is complete, simulate the model again (see Interpret Simulation Results on page
11-29).
In this section...
Introduction
Model with System Tasks
Sample Configured Model with Multiple Target Tasks How Simulink Determines Data Transfer
Requirements
Introduction
A model configured for concurrent execution is a model that is designed to execute concurrently on a
real-time multicore target. Simulink enables you to simulate such models and observe the effects of task-
to-task data transfer. You can also observe how this transfer can impact the numerical characteristics of
the model.
Note The simulation itself does not require a multicore target. The number of tasks that you use to
simulate the design is determined by other factors and does not impose any requirements on the number
of tasks modeled by the design. Factors that influence the concurrency of the simulation include the use
of the Basic Linear Algebra Subprograms (BLAS) library, Rapid Accelerator mode, and the
MATLABparfor command.
Consider the modelsldemo_concurrent_execution.Tounderstand simulation results, compare the signal x

in two scenarios:
Baseline configuration The target has exactly one periodic task and all blocks are mapped to
execute within this task. In this configuration, the target does not allow for any concurrent execution.
Sample configuration The target has three periodic tasks and all blocks are mapped to execute
concurrently in these tasks.
Model with SystemTasks
In the following example, the model is configured as described in Analyze Baseline on page 11-18.
Because this model contains only one sample time (continuous
sampletime),thesampletimeanalysisconfiguresthetarget with one task andmapsallblockstoruninthattask.
Theperiodofthe task is selected as 0.1, which agrees with the fixed-step size of the model. Because the
design has only one task, no task-to-task data transfer is needed. Therefore, simulation of the model
should produce the same numeric results as if the model is not configured for concurrent execution.
Note Configuring a model with sample time analysis system tasks always configures a model to
minimize task-to-task communication requirements. In particular, only those communications that
require rate transitions are included in the design.
Configure the model to inspect data using the Simulation Data Inspector by clicking the Record &
Inspect Simulation Output button in the toolbar. (Alternatively, in the Configuration Parameters dialog
box, select the Data Import/Export > Record and inspect simulation output check box). After you
enable the Simulation Data Inspector, click Simulate > Run to simulate the model using the single task
configuration. After simulation, launch the Simulation Data Inspector as directed in the editor. Observe
that the tool has recorded the simulation results for the signal labeledx.
Sample Configured Model with Multiple Target Tasks
In the Concurrent Execution dialog box, create two additional tasks and map the ControllerA block to
the first additional task and the ControllerB block to the second additional task.
1 Open the Concurrent Execution dialog box.

2 Click the Add Task button twice.
3 Select the first added task and label itControllerA.
4 Select the second added task and label itControllerB.
5In the Map blocks to tasks pane, check that the ControllerA block is assigned to execute within the
ControllerA task and the ControllerB block is assigned to execute within the ControllerB task.
6 Simulate the model again.
7After simulation completes, compare the results for the baseline and custom configurations using the
Simulation Data Inspector.
To understand the source of the phase margin, observe that:
For the first run of the model, signal x, identified by the black line, shows a default task configuration.
In the second run of the model, signal x, identified by the red line, shows a custom task configuration
and the effects of communication latencies from lines crossing task boundaries. This is different from
the first run, which has only one periodic task and therefore, no communication latencies.
The default setting for data transfer is to ensure determinism, so the data transfer is deterministic (see
Data Transfer Options on page 11-21).
Because the data transfer is deterministic, the simulated model takes into account a unit delay to capture
the effects of data transfer. This delay causes a small phase margin in the mapped design. The delay
agrees with the step size of the model, which is 0.1. This delay is the least possible delay that the
software can impose on the signal.
How Simulink Determines Data Transfer Requirements
The software determines data transfer based on how the blocks are mapped to tasks. When a model is
simulated, either from an update diagram or upon code generation, Simulink software examines the
block-to-task mapping and determines which signals must be configured for task-to-task data transfer.
The software considers only the signals where the source of the signal originates from one task and the
destination of the signal resides in a different task. You can specify global options that control data
transfer (see Data Transfer Options on page 11-21). You can also override these options for each signal
from the Data Transfer pane of the Signal Properties dialog box.
Therefore, the block-to-task mapping dictates which blocks execute in which tasks. Consequently, this
mapping also dictates which signals you configure for task-to-task data transfer.
Build and Download to a Multicore Target
In this section...
Generating Code
Configuring Embedded Coder for Native Threads Example Build and Download
Generating Code
To generate code, in the Simulink editor window, select Code > C/C++ Code > Build Model. This code
can run concurrently on a multicore target with Simulink Coder or Embedded Coder software. The coder
generates all target-dependent code for thread creation, thread synchronization, interrupt service
routines, and signal handlers and data transfer. Themain() program contains these threads. The source
files of the mapped model (for example, model.c and model.h) do not contain target-dependent code for
setting up the execution of threads. However, target-dependent code might exist for data transfer types,
which generate target-specific data protection or semaphore application programming interface (API)
calls.
Foreachperiodictask,SimulinkCoder combines the output and update methods of the blocks mapped to
that task and binds these methods to a target-specific thread. Additionally, for each periodic task that
contains continuous states, a separate solver instance is generated in the source file of the mapped
model. This mapped model can concurrently run the continuous parts of the model. (The generated
solver instances share the solver type specified in the Solver of the Configuration Parameters dialog box
of the mapped model.)
For each aperiodic task or aperiodic trigger, Simulink Coder combines the output and update methods of
the blocks mapped to that task and binds these to a target-specific Interrupt Service Routine (ISR) or to a
target-specific event handler.
Following is an example of generated code in the source file of a mapped model. This code shows the
functions generated for the mapped model:
Two solver instances

Three periodic tasks with two of them having continuous states
Two aperiodic tasks
Two aperiodic triggers
/* * This function updates continuous states using the ODE3 fixed-step * solver algorithm */
static void Periodic_Task1_rt_ertODEUpdateContinuousStates(RTWSolverInfo *si ) {}

/* * This function updates continuous states using the ODE3 fixed-step * solver algorithm */
static void Periodic_Task2_rt_ertODEUpdateContinuousStates(RTWSolverInfo *si ) {}

/* OutputUpdate for Task: Periodic_Task1 */ void Periodic_Task1_step(void) /* Sample time: [0.1s, 0.0s] */ {
Periodic_Task1_rt_ertODEUpdateContinuousStates(&task_M[0]->solverInfo);
}
/* OutputUpdate for Task: Periodic_Task2 */ void Periodic_Task2_step(void) /* Sample time: [0.2s, 0.0s] */ {
Periodic_Task2_rt_ertODEUpdateContinuousStates(&task_M[1]->solverInfo);
}
/* OutputUpdate for Task: Periodic_Task3 */ void Periodic_Task3_step(void) /* Sample time: [0.1s,
0.0s] */ {}
/* OutputUpdate for Task: Periodic_Task4 */ void Periodic_Task4_step(void) /* Sample time: [0.2s,
0.0s] */ {}
/* OutputUpdate for Task:Interrupt1_asyncTask1 */ void Interrupt1_asyncTask1(void) {}
/* OutputUpdate for Task:Interrupt2_asyncTask2 */ void Interrupt2_asyncTask2(void) {}
/* OutputUpdate for Task:Interrupt3 */ void Interrupt3(void) {}
/* OutputUpdate for Task:Interrupt4 */ void Interrupt4(void) {}
In addition, for continuous signals, the coder produces code for the extrapolation method that you select.
There are four types of extrapolation methods: zero-order hold, linear, quadratic, and none. None is an
ideal case when the two communicating tasks synchronize in minor steps.
The following code snippets contain the generated task functions in the source file of the mapped model.
Thesldemo_concurrent_execution model has been modified so that:
ControllerA/u1 usesEnsure data Integrity only option in the Signal Properties dialog box.
Plant is remapped to a new task that executes concurrently with Compensator. The data transfer from
Plant to Compensator isEnsure deterministic transfer (minimum delay).
The coder makes sure that the data transfer between concurrently executing tasks behave as described
Data Transfer Options on page 11-21.
Generate Code to Share Data in a Concurrent Environment ForEnsure data integrity only, the
generated code allows data to be shared in a concurrent environment. This is achieved with a double-
buffer algorithm (for same rate data transfer) and a triple buffer algorithm (for rate-transition data
transfer) and target-specific protection code for the buffer flag management. The following example
shows code generated using the sldemo_concurrent_execution model:
1 Open the Signal Properties dialog box for ControllerA/u1 and selectData Integrity Only as the data
transfer handling option from the Data Transfer pane.
2To generate code, select Code > C/C++ Code > Build Model.
The coder generates code like the following. This code is for ControllerA/u1 on the Linux platform.
/* Output for Task: Periodic_ControllerA */ void Periodic_ControllerA_output(void) /* Sample time: [0.1s, 0.0s] */ {
/* TaskTransBlk: '<Root>/TaskTransAtController AOut1' */ sldemo_concurrent_execution_DWork.

TaskTransAtControllerAOut1_buf_3[sldemo_concurrent_execution_DWork.fw_buf_3]
= sldemo_concurrent_execution_B.ControllerA; rtw_pthread_mutex_lock(sldemo_concurrent_execution_DWork.mw_buf_3);
sldemo_concurrent_execution_DWork.fw_buf_3 = 1
sldemo_concurrent_execution_DWork.fw_buf_3; rtw_pthread_mutex_unlock(sldemo_concurrent_execution_DWork.mw_buf_3); } /* Output for
Task: Periodic_Plant */ void Periodic_Plant_output(void) /* Sample time: [0.0s, 0.0s] */ {
if (rtmIsMajorTimeStep(task_M[2])) { /* TaskTransBlk: '<Root>/TaskTransAtPlantIn1' */

rtw_pthread_mutex_lock(sldemo_concurrent_execution_DWork.mw_buf_3); wrBufIdx = 1 - sldemo_concurrent_execution_DWork.fw_buf_3;
rtw_pthread_mutex_unlock(sldemo_concurrent_execution_DWork.mw_buf_3); sldemo_concurrent_execution_B.TaskTransAtPlantIn1 =
sldemo_concurrent_execution_DWork.TaskTransAtControllerAOut1_buf_3[wrBufIdx];
}
} void MdlInitialize(void) {
sldemo_concurrent_execution_DWork.fw_buf_3 = 0;
rtw_pthread_mutex_init(&sldemo_concurrent_execution_DWork.mw_buf_3);
}
Generate Code for Maximum Capacity During Data Transfer
For Ensure deterministic transfer (maximum delay), the generated code for the task transition is ANSI
C code with writing and reading to and from double buffers. In the Signal Properties dialog box, you
provide a value for the Initial Condition value that initializes the buffer used for the first read operation.
The software generates code like the following. This example is for ControllerB/u1 on the Linux
platform.
/* Output for Task: Periodic_ControllerB */ void Periodic_ControllerB_output(void) /* Sample time: [0.1s, 0.0s] */ {
sldemo_concurrent_execution_DWork. TaskTransAtControllerBOut1_buf_4[sldemo_concurrent_execution_DWork.fw_buf_4] =
sldemo_concurrent_execution_B.ControllerB;
sldemo_concurrent_execution_DWork.fw_buf_4 = 1 sldemo_concurrent_execution_DWork.fw_buf_4; } /* Output for Task: Periodic_Plant */ {
void Periodic_Plant_output(void) /* Sample time: [0.0s, 0.0s] */

if (rtmIsMajorTimeStep(task_M[2])) {
/* TaskTransBlk: '<Root>/TaskTransAtPlantIn2' */ sldemo_concurrent_execution_B.TaskTransAtPlantIn2 =
sldemo_concurrent_execution_DWork.
TaskTransAtControllerBOut1_buf_4[sldemo_concurrent_execution_DWork.fr_buf_4]; sldemo_concurrent_execution_DWork.fr_buf_4 = 1
sldemo_concurrent_execution_DWork.fr_buf_4; }
}
void MdlInitialize(void) {
/* InitializeConditions for TaskTransBlk: '<Root>/TaskTransAtController BOut1' */
sldemo_concurrent_execution_DWork.fw_buf_4 = 0;
}
Generated Code for Maximum Data Integrity During Data Transfer

ForEnsure deterministic transfer (minimum delay), the generated code for the data transfer makes sure
that the task reading the data is waiting for the task writing the data to complete its computation of the
data. This behavior produces target-specific code for data synchronization (for example, semaphores).
The software generates code like the following. This example code is for Plant/x on the Linux platform.
/* * This function updates continuous states using the ODE3 fixed-step * solver algorithm
*/
static void Periodic_Compensator_rt_ertODEUpdateContinuousStates(RTWSolverInfo *si )
{
/* TaskTransBlk: '<Root>/TaskTransAtCompensatorIn1' */ if
(sldemo_concurrent_execution_DWork.br_buf_5) {
sldemo_concurrent_execution_DWork.br_buf_5 = FALSE;
} else {
rtw_pthread_sem_wait(sldemo_concurrent_execution_DWork.sw_buf_5);
sldemo_concurrent_execution_B.TaskTransAtCompensatorIn1 =
sldemo_concurrent_execution_DWork.TaskTransAtPlantOut1_buf_5;
rtw_pthread_sem_post(sldemo_concurrent_execution_DWork.sr_buf_5); if (rtmIsMajorTimeStep(task_M[0])) {
sldemo_concurrent_execution_DWork.br_buf_5 = TRUE; }
}
/* End of TaskTransBlk: '<Root>/TaskTransAtCompensatorIn1' */
}
/* Output for Task: Periodic_Plant */
void Periodic_Plant_output(void) /* Sample time: [0.0s, 0.0s] */ {
if (rtmIsMajorTimeStep(task_M[3])) {
/* TaskTransBlk: '<Root>/TaskTransAtPlantOut1' */
rtw_pthread_sem_wait(sldemo_concurrent_execution_DWork.sr_buf_5);
sldemo_concurrent_execution_DWork.TaskTransAtPlantOut1_buf_5 =
sldemo_concurrent_execution_B.x;
rtw_pthread_sem_post(sldemo_concurrent_execution_DWork.sw_buf_5); }
void MdlInitialize(void)
{
}
/* InitializeConditions for TaskTransBlk: '<Root>/TaskTransAtPlantOut1' */ sldemo_concurrent_execution_DWork.fw_buf_5

= 0;
rtw_pthread_sem_create(&sldemo_concurrent_execution_DWork.sw_buf_5, 0);
Threading APIs
For Embedded Coder targets and generic real-time targets, the generated code from a mapped model
creates a thread for each task and automatically leverages the threading APIs supported by the operating
system running on the host machine.
If the host machine is a Windows platform, the generated code will create and run Windows threads.
If the host machine is Linux or Mac OS platform, the generated code will create and run POSIX
pthreads.
Aspect of
Concurrent
Execution
Periodic triggering event

Linux
Implementation Windows
Implementation Mac OS
Implementation
POSIX timer Windows timer Not applicable

Aperiodic triggering event
Aperiodic trigger
Threads POSIX real-time

signal
For blocks mapped to an aperiodic task: thread waiting for a signal
For blocks mapped to an aperiodic trigger: signal action
POSIX
Windows event
Thread waiting for an event
Windows POSIX non-real-time signal
For blocks mapped to an aperiodic task: thread waiting for a signal
For blocks mapped to an aperiodic trigger: signal action
POSIX
Aspect of
Concurrent
Execution
Threads priority
Example of overrun detection
Linux
Implementation Windows
Implementation
Assigned based on sample time: fastest task has highest priority
Yes Priority class

inherited from the parent process.
Assigned based on sample time: fastest task has highest priority for the first three fastest tasks. The rest
of the tasks share the lowest priority.
Yes
Assigned based on sample time: fastest task has highest priority
No
The data transfer between concurrently executing tasks behave as described in Data Transfer Options on
page 11-21. The coders use the following APIs on supported targets for this behavior:
Data Protection and Synchronization APIs that Embedded Coder and Generic Real-Time Targets
Use
API Linux Implementation
Data protection pthread_mutex_init API pthread_mutex_destroy
pthread_mutex_lock
pthread_mutex_unlock
Synchronization sem_init
API
sem_destroy
Windows
Implementation
CreateMutex
CloseHandle
WaitForSingleObject
ReleaseMutex
CreateSemaphore
CloseHandle
Mac OS
Implementation
pthread_mutex_init
pthread_mutex_destroy
pthread_mutex_lock
pthread_mutex_unlock
sem_open
sem_unlink
Data Protection and Synchronization APIs that Embedded Coder and Generic Real-Time Targets
Use (Continued)
API Linux Implementation Windows
Implementation
sem_wait
sem_post
WaitForSingleObject
ReleaseSemaphore
sem_wait
sem_post
Themain() code is always dynamically generated. The general structure of the generated main file is
depicted in the following pseudocode:
main() {
Model_initialize(); For_each_periodic_task {
Create_synchronization_event(periodic_task); Create_thread(periodic_task);
}
For_each_aperiodic_task {
Create_external_event(aperiodic_task); Create_thread(aperiodic_task);
}
Create_timer();
Create_thread(Periodic_task_scheduler);
For_each_aperiodic_trigger {
Hookup_isr_to_aperiodic_event(); }
Wait_for_stopping(); Cleanup();
Model_terminate(); return 0;
}
Periodic_task_scheduler() {
Wait_for_event_from_timer(clock); For_each_periodic_task
{
If periodic_task has a sample time hit Set the event to run the task
}
}
Periodic_Task() {
Wait_for_event(Periodic_task_scheduler); Run the appropriate periodic_task();
}
Aperiodic_Task() {
Wait_for_aperiodic_event();
Run the appropriate aperiodic_task();
}
Isr() {
Run the appropriate aperiodic_trigger (); }
Configuring Embedded Coder for Native Threads Example
To generate code for an Embedded Coder target, in the Configuration Execution dialog box:
Select the Code Generation > Templates > Generate an example main program check box.
From the Code Generation > Templates > Target Operating System list,
selectNativeThreadsExample.
Build and Download
You can build and download concurrent execution models for the following targets using system target
files:
Linux, Windows, and Mac OS usingert.tlc and grt.tlc.

xPC Target usingxpctarget.tlc andxpctargetert.tlc.
Linux and Windows usingidelink_ert.tlc andidelink_grt.tlc.
Embedded Linux and VxWorks usingidelink_ert.tlc and

idelink_grt.tlc.
Note Deploying to embedded Linux and VxWorks targets requires the Embedded Coder product.
You cannot generate code for C++ (Encapsulated) language option.
Profile the execution of your code on the multicore system using the Profile Report pane of the
Concurrent Execution dialog box. You can profile using Simulink Coder (GRT) and Embedded Coder
(ERT) targets. Profiling helps you identify the areas in your model that are execution bottlenecks. You
can analyze the execution time of each task and find the task that takes most of the execution time. For
example, you can compare the average execution times of the tasks. If a task is computation intensive, or
does not satisfy real-time requirements and overruns, you can break it into tasks that are less
computation intensive and that can run concurrently.
When you generate a profile report, the software:
1 Builds the model.
2 Generates code for the model.
3Addstoolingtothegeneratedcodetocollectdata.
4 Executes the generated code on the target and collects data.
5Collates the data, generates an HTML file

(model_name_ProfileReport.html) in the current folder, and displays that HTML file in the Profile
Report pane.
Note If an HTML profile report exists for the model, the Profile Report
pane displays that file. To generate a new profile report, click .

Section Summary
Task Execution Time
Task Affinitization to Processor Cores
Description
Summarizes model execution statistics, such as total execution time and profile report creation time. It
also lists the total number of core processes on the host machine.
Displays the execution time, in microseconds, for each task in a pie chart color coded by task. Visible
for Windows, Linux, and Mac OS platforms.
Platform-dependent. For each time step and task, displays the processor number the task was executing
on at that time step, color coded by processor.
If there is no task scheduled for a particular time step,NR is displayed.

Visible for Windows and Linux platforms.
After you analyze the profile report, consider explicitly changing the mapping of Model blocks to
efficiently use the concurrency available on your multicore system (see Map Blocks to Tasks
Incrementally on page 11-26).
Some products, such as xPC Target and Embedded Coder, have tools you can usetoprofileexecutionfor
particular targets:
Product For more information, see... xPC Target Profiling Target Application Execution
Embedded Coder Execution Profiling for Embedded Targets
This topic assumes you have a model you have already configured for concurrent execution that you
want to profile. If you to do have a model configured that way, see Configure Your Model on page
11-12.
1In the Concurrent Execution dialog box, click the Profile report node. The profile tool looks for a file
named model_name_ProfileReport.html. If such a file does not exist for the current model, the Profile
Report pane displays:
Note If an HTML profile

report exists for the model, the Profile Report
pane displays that file. To generate a new profile report, click
.
2 Enter the number of time steps for which you want the profiler to collect data for the model execution.
3 Click the Generate task execution profile report button.
This action builds the model, generates the code, adds data collection tooling to the code, and then
executes the code on the target, which also generates an HTML profile report. This process can take
several minutes. When the process is complete, the contents of the profile report appear in the Profile
Report pane. For example:
4 Analyze the profile report, create and reassign new tasks as needed, and
regenerate the profile report.
Generate Profile Report at Command Line

Alternatively, you can generate a profile report for a model configured for concurrent execution at the
command line. Use the Simulink.SoftwareTarget.profile function.
Forexample, tocreateaprofilereportfor themodel sldemo_concurrent_execution:
Simulink.SoftwareTarget.profile('sldemo_concurrent_execution');
To create a profile report with a specific number of samples (100) for the
modelsldemo_concurrent_execution:
Simulink.SoftwareTarget.profile('sldemo_concurrent_execution',120);
The function creates a profile report named
sldemo_concurrent_execution_ProfileReport.html in your current folder.
For an interactive example of a model that has been configured to work in a concurrent execution
environment:
1 In the MATLAB Command Window, click the question mark.
The Documentation Center window opens.
2Navigate to Simulink > Examples > Modeling Features > Modeling Concurrency > Modeling
Concurrent Execution on Multi-Core Targets.
Modeling Concurrent Execution on Multicore Targets
This model shows how you can use Simulink and Simulink Coder to realize concurrent execution of a
model on a multicore target. Additionally, the example illustrates how simulation captures effects of on-
target concurrent execution, such as the transfer of data between tasks. This example also shows how
you can specify and simulate the effects of asynchronous external inputs to your system via the root
input port.
Example Requirements
If you want to generate code for this model, install Simulink Coder. Note, when you simulate the
example, Simulink and Simulink Coder might generate code in the current working folder. If you do
not want to (or cannot) generate files in this folder, change the current working folder.
topmdl = 'sldemo_concurrent_execution'; open_system(topmdl);

curDir = pwd;
cd(tempdir);
Overview of the
Model
To take advantage of the concurrent execution feature, use Model blocks to partition your model into
portions that can potentially execute concurrently. Open the model and examine its partitioning into four
Model blocks: Plant, Compensator, ControllerA, and ControllerB.
Exploring Concurrent Execution
This feature allows you to map Model block partitions to tasks via a mapping interface. Mapping Model
blocks to different tasks allows these Model blocks to execute concurrently on a real-time target.
To experiment with the mapping interface, consider changing the task configuration. Do this by adding
or deleting tasks and using the Map blocks to tasks panel (as shown below) to reassign model block
partitions as needed. For more information, see documentation. Mapping may be performed
interactively or by using programmaticAPIs. Forexample,thefollowing command line instructions show
how to configure the model as shown in the illustration below.
Now, simulate the model and examine the effects of your mapping. In particular, the Simulink editor
shows the intertask communication via the
new
icons representing that the communication introduced a unit delay.
% Enable the external inputs to the system.

set_param(topmdl, 'LoadExternalInput', 'on');
% Get active configuration set

csTop = getActiveConfigSet(topmdl);
% Get the task configuration.
tc = csTop.concurrentExecutionComponents;
% Get the block handles for mapping.

plantBlkH = get_param([topmdl '/Plant'], 'Handle'); compensatorBlkH = get_param([topmdl
'/Compensator'], 'Handle'); controlABlkH controlBBlkH interruptBlkH = get_param([topmdl
'/Controller A'], 'Handle'); = get_param([topmdl '/Controller B'], 'Handle'); = get_param([topmdl
'/Interrupt'], 'Handle');
% Delete any previously created tasks periodicTrigger = tc.Triggers(1);

periodicTasks = periodicTrigger.Tasks; tnames = {periodicTasks.Name}; for i = 1:length(periodicTasks)
periodicTrigger.deleteTask(tnames{i}); end
% Delete aperiodic trigger

aperiodicTrigger = tc.Triggers(2); tc.deleteTrigger(aperiodicTrigger);
% Create and configure new tasks. plant
controlA controlB = periodicTrigger.addTask('Plant'); = periodicTrigger.addTask('ControllerA'); =
periodicTrigger.addTask('ControllerB');
interruptSource = tc.addAperiodicTrigger('Interrupt');
plant.Period = '0.1'; controlA.Period = '0.1'; controlB.Period = '0.1';
% Perform mapping of blocks to tasks. tc.map(plantBlkH, plant);

tc.map(compensatorBlkH, plant);
tc.map(controlABlkH, controlA);
tc.map(controlBBlkH, controlB);
tc.map(interruptBlkH, interruptSource);
% Launch Concurrent Execution dialog
Simulink.SoftwareTarget.concurrentExecution(topmdl, ... 'OpenDialog', ... 'Configuration');
sim(topmdl);
Viewing Simulation Results
You can use the Simulation Data Inspector to view the simulation results.
Theresultsmaybeusedtoobserveboth communication effects (discussed above) as well as aperiodic
events. The illustration below shows how the system reacts to events specified at
times4and7intheDataImport/Export panel of the Configuration Parameters dialog.
Configuring Intertask Communication
You can change the modes of the intertask communication between the Model blocks in the model to
better suit design criteria. Do this by clicking the link or by following these instructions:
Click on the Data Transfer node of the Concurrent Execution dialog. In the Data Transfer Options
pane, change Defaults > Periodic signals toEnsure data integrity only by selecting it. Click Apply to
save the changes.
Now, simulate the model. The lock icon on the signals between the Model blocks indicates that data
transfer between concurrent tasks is performed in data-integrity-only mode. For fine-grained control on
the data transfer modes between tasks at the level of individual signals, see the documentation.
Generating Code and Profile Report

Generate code and profile report from the model.
The profile report shows how generated code executes on a host computer. For the example profile
report illustrated below, the generated code was run on a four core processor host computer. The Task
Execution Time section lists the times in microseconds. The Task Affinitization to Processor Cores
section shows how the tasks execute concurrently on the different cores. For details of how concurrent
execution is achieved, examine the code illustrated in the Code Generation report or see the
documentation.
11-58
close_system([topmdl,'_compensator'], 0); close_system([topmdl,'_controller_A'], 0);
close_system([topmdl,'_controller_B'], 0); cd(curDir);
Conclusion
This example illustrates a simple workflow using Simulink and Simulink Coder to examine the effects
of concurrent execution on a multicore target. You can iteratively apply this workflow to optimize
performance of a real-world application on a multicore xPC Target environment, along with the on-
target profiling capability of xPC Target.
The previous topics describe how to configure models for concurrent execution using the Simulink
Configuration Execution dialog box. You can also perform the configuration using a command-line
interface. The following classes, their methods and properties, and the
Simulink.SoftwareTarget.concurrentExecution function comprise this interface:
To...
Create a configuration set for concurrent execution
Specify aperiodic
trigger
Use...
Simulink.SoftwareTarget.concurrentExecution
Simulink.SoftwareTarget.AperiodicTrigger
Specify periodic trigger Simulink.SoftwareTarget.PeriodicTrigger
Specify aperiodic trigger for POSIX targets
Specify task that models unit of

concurrent execution
Configure model for concurrent execution
Specify base class for PeriodicTrigger and AperiodicTrigger
Describe aperiodic trigger for Windows target
Configure concurrent execution data

transfers
Simulink.SoftwareTarget.PosixSignalHandler
Simulink.SoftwareTarget.Task
Simulink.SoftwareTarget.TaskConfiguration
Simulink.SoftwareTarget.WindowsEventHandler
Simulink.SoftwareTarget.Trigger
Simulink.GlobalDataTransfer

SIMULINK. Exploring - Searching and Browsing Models

Uploaded by

Copyright:

Available Formats

SIMULINK. Exploring - Searching and Browsing Models

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SIMULINK. Exploring - Searching and Browsing Models

Uploaded by

Copyright:

Available Formats

SIMULINK

Exploring, Searching and Browsing Models

Model Explorer Overview

Model Explorer: Model Hierarchy Pane

Model Explorer: Contents Pane

Contents Pane Tabs

Control Model Explorer Contents Using Views Using Views

Organize Data Display in Model Explorer Layout Options

Workspace Variables in Model Explorer

Model Dependency Viewer

About Model Configurations

Manage a Configuration Set

Manage a Configuration Reference

About Configuration Sets

About Configuration References

Configuring Models for Targets with Multicore Processors

Introduction to Concurrent Execution

Design Considerations5 Modeling for Concurrency Simulation Limitations

Modeling Process for Concurrent Execution

Configure Your Model

Analyze Baseline Customize Concurrent Execution Settings Configuring Data Transfer

Interpret Simulation Results

Build and Download to a Multicore Target Generating Code

Concurrent Execution Example Model

Exploring, Searching, and Browsing Models

Model Explorer Overview

What You Can Do Using the Model Explorer

Opening the Model Explorer

To open the Model Explorer, use one of these approaches:

Model Explorer Components

Model Hierarchy pane Contents pane Dialog pane

Dialog pane Purpose

Execute Model Explorer commands

Display and modify model or chart objects

Model Explorer: Model Hierarchy Pane on page 9-9

Model Explorer: Contents Pane on page 9-19

The Main Toolbar

Showing and Hiding the Main Toolbar

Controlling the Font Size

Focusing on Specific Elements of a Model or Chart

Show partial or whole model hierarchy

Use the Row Filter option

To control how much of a hierarchical model to display

To focus on, or hide, a specific kind of a model object, such as signals

Displaying Partial or Whole Model Hierarchy Contents on page 9-12

Using the Row Filter Option on page 9-46

To quickly organize data for a property in ascending or

To logically group data based on values for a property

To display a named subset of property columns to apply to different kinds of

To customize property columns

Sorting Column Contents on page 9-36

How to Group by a Property Column on page 9-39

Organize Data Display in Model Explorer on page 9-36

Model Explorer: Model Hierarchy Pane

What You Can Do with the Model Hierarchy Pane

Finding Variables That Are Used by a Model or Block on page 9-52

Editing Workspace Variables on page 9-58

Expand a node representing a subsystem to display underlying subsystems, if any.

Select View > Show Current System and Below.