Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink |
| Contents | Index |
| Learn more about Simulink |
Use the Simulink Model Advisor checks to configure your model for simulation.
Consulting Model Advisor in the Simulink documentation.
Real-Time Workshop Model Advisor Check Reference in the Real-Time Workshop documentation.
Simulink Verification and Validation Model Advisor Check Reference in the Simulink Verification and Validation documentation.
Uses the slupdate command analysis mode to check for common upgrade issues.
Check blocks, settings, and references in the model for compatibility issues resulting from using a new version of Simulink software.
| Condition | Recommended Action |
|---|---|
| Referenced models recommended for update. | Run Simulink update tool, slupdate on the listed models. |
| Check library update status. | Verify that indicated libraries are valid. |
| Check update status for the Level 2 API S-functions. | Consider replacing Level 1 S-functions with Level 2. |
| Blocks have configuration sets or ports with undesired settings. | Run Simulink update tool, slupdate, in update mode. |
slupdate in the Simulink documentation.
Writing S-Functions in the Simulink documentation.
Check for unconnected lines or ports.
This check lists unconnected lines or ports. These can have difficulty propagating signal attributes such as data type, sample time, and dimensions.
| Condition | Recommended Action |
|---|---|
| Lines, input ports, or output ports are unconnected. | Ensure all signals are connected. Double-click the list of unconnected items to locate failure. |
Use the PortConnectivity command to obtain an array of structures describing block input or output ports.
Common Block Parameters in the Simulink documentation for information on the PortConnectivity command.
Check that root model Inport blocks fully define dimensions, sample time, and data type.
Using root model Inport blocks that do not fully define dimensions, sample time, or data type can lead to undesired simulation results. Simulink software back-propagates dimensions, sample times and data types from downstream blocks unless you explicitly assign them values.
| Condition | Recommended Action |
|---|---|
| Root-level Inport blocks have undefined attributes. | Fully define the attributes of all root-level Inport blocks. |
Working with Data Types in the Simulink documentation.
Determining Output Signal Dimensions in the Simulink documentation.
How to Specify the Sample Time in the Simulink documentation.
Check for optimizations that can lead to nonoptimal code generation and simulation.
This check reviews the status of optimizations that can improve code efficiency and simulation time.
| Condition | Recommended Action |
|---|---|
| The specified optimizations are off. | Select the following optimization check boxes in the Optimization pane of the Configuration Parameters dialog box: |
| Application lifespan (days) is set as infinite. This could lead to expensive 64-bit counter usage. | Choose appropriate stop time if this is not intended. |
| The specified diagnostics, which can increase the time it takes to simulate your model, are set to warning or error. | Select none for:
|
| The specified Real-Time Workshop Embedded Coder parameters are off. | If you have a Real-Time Workshop Embedded Coder license, and
you are using an ERT-based system target file, select the following
check boxes:
|
If the system contains Model blocks and the referenced model is in Accelerator mode, simulating the model requires generating and compiling code.
Optimization Pane in the Simulink documentation.
Optimizing Generated Code in the Real-Time Workshop documentation.
Preparing Models for Code Generation in the Real-Time Workshop Embedded Coder documentation.
Checks if parameter tunability information is included in the Model Parameter Configuration dialog box.
Simulink software ignores tunability information specified in the Model Parameter Configuration dialog box. This check identifies those models containing parameter tunability information that Simulink software will ignore if the model is referenced by other models.
| Condition | Recommended Action |
|---|---|
| Model contains ignored parameter tunability information. | Click the links to convert to equivalent Simulink parameter objects in the MATLAB workspace. |
Parameter Considerations in the Simulink documentation.
Identify models that attempt to resolve named signals and states to Simulink.Signal objects.
Requiring Simulink software to resolve all named signals and states is inefficient and slows incremental code generation and model reference. This check identifies those signals and states for which you may turn off implicit signal resolution and enforce resolution.
| Condition | Recommended Action |
|---|---|
| Not all signals and states are resolved. | Turn off implicit signal resolution and enforce resolution for each signal and state that successfully resolves. |
Resolving Signal Objects for Output Data in the Simulink documentation.
Identify virtual buses that could be made nonvirtual. Making these buses nonvirtual improves generated code efficiency.
This check identifies blocks incorporating virtual buses that cross a model boundary. Changing these to nonvirtual improves generated code efficiency.
| Condition | Recommended Action |
|---|---|
| Blocks that specify a virtual bus crossing a model boundary. | Change the highlighted bus to nonvirtual. |
Working with Signals in the Simulink documentation.
Virtual and Nonvirtual Buses in the Simulink documentation.
Identify Discrete-Time Integrator blocks with state ports and initial condition ports that are fed by neither an Initial Condition nor a Constant block.
Discrete-Time Integrator blocks with state port and initial condition ports might not be properly initialized unless they are fed from an Initial Condition or Constant block. This is more likely to happen when Discrete-Time Integrator blocks are used to model second-order or higher-order dynamic systems.
| Condition | Recommended Action |
|---|---|
| Discrete-Time Integrator blocks are not initialized during the model initialization phase. | Add a Constant or Initial Condition block to feed the external Initial Condition port. |
IC block
Discrete-Time Integrator block
Constant block
Search model for disabled library links.
Disabled library links can cause unexpected simulation results. All disabled links should be resolved before a model is saved.
Note This check may overlap with Check model, local libraries, and referenced models for known upgrade issues. |
| Condition | Recommended Action |
|---|---|
| Library links are disabled. | Use Restore Link from the Link Options setting in the context menu. |
Use the Model Browser to find library links.
To enable a broken link, right-click a block in your model to display the context menu. Choose Link Options and click Restore Link.
The Model Browser in the Simulink documentation.
Search model for parameterized library links.
Parameterized library links that are unintentional can result in unexpected parameter settings in your model. This can result in improper model operation.
| Condition | Recommended Action |
|---|---|
| Parameterized links are listed. | Verify that all parameterized links are intended. |
Right-click a block in your model to display the context menu. Choose Link Options and click Go To Library Block to see the original block from the library.
To parameterize a library link, choose Look Under Mask, from the context menu and select the parameter.
Working with Block Masks in the Simulink documentation.
Search the model for unresolved library links, where the specified library block cannot be found.
Check for unresolved library links. Models do not simulate while there are unresolved library links.
| Condition | Recommended Action |
|---|---|
| Library links are unresolved. | Locate missing library block or an alternative. |
Fixing Unresolved Library Links
Look for modeling issues related to Data Store Memory blocks.
Checks shadowing of data stores of higher scope, strong typing, multitasking data integrity, and runtime diagnostics.
| Condition | Recommended Action |
|---|---|
| Data Store blocks have duplicate names. | Give each Data Store block in the model a unique name. |
| Data Store blocks are not strongly typed. | Specify a data type other than Inherit: auto. |
| Multiple tasks access the same data store. | Change the model to avoid multitask data stores. |
| Reading and writing occur out of order. | Restructure and prioritize so enforce correct order. |
| Multiple writes occur within a single time step. | Change the model to write data only once per step. |
Identify Mux blocks used as a bus creator and any bus signal that is treated as a vector.
Models should not contain bus signals that Simulink software implicitly converts to vectors. Instead, either insert a Bus to Vector conversion block between the bus signal and the block input port that it feeds, or use the Simulink.BlockDiagram.addBusToVector command.
Note You should always run this check before running Check consistency of initialization parameters for Outport and Merge blocks. |
| Condition | Recommended Action |
|---|---|
| Identify signals used as vectors. | In the Configuration Parameters dialog box, set Mux blocks used to create bus signals to error. |
| Model uses buses properly. | In the Configuration Parameters dialog set Bus signal treated as vector to error. |
| Bus signals are implicitly converted to vectors. | Use Simulink.BlockDiagram.addBusToVector or insert a Bus to Vector block. |
The Bus to Vector conversion block is located in the Simulink/Signal Attributes library.
Identify function-call return values that might be delayed because Simulink software inserted an implicit Signal Conversion block.
To ensure that signals reside in contiguous memory, Simulink software can automatically insert an implicit Signal Conversion block in front of function-call initiator block input ports. This can result in a one-step delay in returning signal values from calling function-call subsystems. The delay can be avoided by ensuring the signal originates from a signal block within the function-call system. Or, if the delay is acceptable, insert a Unit Delay block in front of the affected input ports.
| Condition | Recommended Action |
|---|---|
| The listed block input ports could have an implicit Signal Conversion block. | Decide if a one-step delay in returning signal values is acceptable
for the listed signals.
|
Signal Conversion block
Unit Delay block
Find continuous sample time, non-floating-point output signals.
Non-floating-point signals cannot properly represent continuous variables.
| Condition | Recommended Action |
|---|---|
| Signals with continuous sample times have a non-floating-point data type. | On the identified signals, either change the sample time to be discrete or fixed-in-minor-step ([0 1]). |
Working with Sample Times in the Simulink documentation.
Analyze Merge blocks in the same tree as a group, and determine the possibility for them to execute at the same time step.
Blocks that directly drive the same tree of Merge blocks should have mutually exclusive execution in each time step. This check identifies those blocks that drive the same tree of Merge blocks, and so are likely to execute at the same time step.
| Condition | Recommended Action |
|---|---|
| Merge blocks can be interconnected to form a tree structure. | Rework your model so that no blocks drive the same tree of Merge blocks. |
Identify Outport and Merge blocks with parameter settings that can lead to unexpected initialization behavior, and migrate your model to simplified initialization mode.
In R2008b or later, you can choose simplified initialization mode for conditionally executed subsystems, Merge blocks, subsystem elapsed time, and Discrete-Time Integrator blocks. Simplified initialization mode improves the consistency of simulation results, especially for models that do not specify initial conditions for conditionally executed subsystem output ports, and for models that have conditionally executed subsystem output ports connected to S-functions.
This Model Advisor check identifies settings in your model that can cause problems when using simplified initialization mode. There are two types of messages in this check, errors and warnings. Error messages identify issues that you need to address manually before the model can be migrated to simplified initialization mode. Warning messages identify issues or changes in behavior that may occur after migration.
Note Before running this check, run the check: Check for proper bus usage to ensure that Merge blocks are used correctly, and enable strict Merge run-time diagnostics. |
After running this check, select the Explore Result button to access the blocks listed in each message, with the exception of library-linked blocks.
Once you have addressed all issues identified by the check, select Proceed to migrate your model to the simplified initialization mode.
Note Because it is difficult to undo these changes, save a backup copy of your model and libraries before migrating to simplified initialization mode. |
| Condition | Recommended Action | |
|---|---|---|
| Error: Strict Bus Mode Must Be Enabled |
| |
| Error: Strict Merge Run-Time Diagnostics Must Be Enabled | In the model window:
| |
| Error: Referenced Models Not Yet Migrated | Migrate the model referenced by the Model block to simplified initialization mode, then migrate the top model. | |
| Error: Single-Input Merge Blocks | Replace both the Mux block used to produce the
input signal and the Merge block with one multi-input Merge block. Single-input Merge blocks are not supported in simplified initialization mode. | |
| Error: Root Merge Blocks With Unspecified Initial Output | Specify an explicit value for the Initial output parameter
of the root Merge block. A root Merge block is any Merge block with an output port that does not connect to another Merge block. | |
| Error: Merge Blocks With Non-zero Input Port Offsets | Deselect the Allow unequal port widths parameter of the Merge block. | |
| Error: Merge Blocks With Unconnected Inputs or Inputs from Non-Conditionally Executed Subsystem | Set the Number of inputs parameter of
the Merge block to the correct number of inputs, so that each input
is connected to a signal. Ensure that the Merge block inputs are each driven by a conditionally executed subsystem. Merge blocks cannot be driven directly by an Iterator Subsystem or any block that is not a conditionally executed subsystem. | |
| Error: Merge Blocks With Inputs That Have Been Combined Or Reordered Outside of Conditionally Execute Subsystems | Ensure that any combination or reordering of Merge block input signals (using Mux, Bus Creator, or Selector blocks, for example) takes place within a conditionally executed subsystem. | |
| Error: Merge Blocks With Inconsistent Input Sample Times | Ensure that each input signal has the same Sample time. | |
| Error: Merge Blocks With Multiple Input Ports Driven By Same Source | Ensure that the Merge block does not have multiple input signals that are driven by the same conditionally executed subsystem or conditionally executed Model block. | |
| Error: Outport Blocks With Conflicting Buffer Requirements | The Outport block has function-call trigger or function-call
data dependency signal passing through it, along with regular signals.
Some of the regular data signals require an explicit signal buffer
to ensure correct initialization of the corresponding subsystem's
output signal. However, buffering function-call related signals will
lead to a function-call data dependency violation. Consider modifying the model to pass function-call related signals through a separate Outport. For examples of function-call data dependency violations, see the demo model sl_subsys_semantics. | |
| Error: Outports Requiring Explicit Bus Copy | An explicit copy of the bus signal driving the Outport block
is needed to ensure correct initialization of the corresponding subsystem's
output signal. Insert a Signal Conversion block before the Outport block, then set the Output parameter of the Signal Conversion block to Bus copy. | |
| Error: Outport Blocks Being Merged But Can Reset When Disabled | Set the Output when disabled parameter
of the Outport block to held. For more information, see the Outport block documentation. | |
| Error: Outport Blocks With Unspecified Initial Output | Specify the Initial output parameter for
the Outport block, unless you want the block to obtain
its initial output value from its input signal. If you want the Outport block to obtain its initial output value from its input signal, ensure that all of its sources are valid initial output value sources. Outport blocks can inherit initial output value from Constant, Initial Condition, Merge (with initial output), or conditionally executed subsystem blocks.
| |
| Error: Outport Blocks With Automatic Rate Transitions | Simulink has inserted Rate Transition blocks on the input signals
of the Outport block. If such rate transitions are needed, specify the Initial output parameter for each Outport block. Otherwise, perform the following procedure:
| |
| Error: Outport Blocks Require Explicit Initial Output | Specify the Initial output parameter for the Outport block. The Outport block cannot obtain initial output values from its input signals due to Simulink internal signal storage handling. | |
| Error: Outport Blocks Reset When Disabled With Unspecified Initial Output | Specify the Initial output parameter of
the Outport block. You must specify the initial output value for blocks that are configured to reset when disabled. | |
| Error: Outport Blocks Passing Through Function-call Data Dependency Signal Must Not Have Initial Output Value | You cannot specify an Initial output value for the Outport block because function-call data dependency signals are passing through it. To set the initial output value:
| |
| Error: Blocks Requiring Elapsed Timer Will Not Be Allowed In Iterator Subsystem | Within an Iterator subsystem hierarchy, do not use blocks that
require a service that maintains the time that has elapsed between
two consecutive executions. Since Iterator subsystem can be executed multiple times at a given time step, the concept of elapsed time is not well-defined between two such executions. Using these blocks inside an Iterator subsystem can cause unexpected behavior. | |
| Warning: Outport Blocks Initial Output Value Can No Longer Be Specified By Signal Objects | Ensure that the following behavior is acceptable. The Initial output parameter of the Outport block cannot be specified by signal objects. You can initialize the input or output signals for an Outport block using signal objects, but the initialization results may be overwritten by that from the Outport block. | |
| Warning: Outport Blocks Being Merged But Is Unconnected Or Connected To Ground Block | Ensure that the following behavior is acceptable. The Outport block is driving a Merge block, but its inputs are either unconnected or connected to Ground blocks. In classic initialization mode, unconnected or grounded outports do not update the merge signal even when their parent conditionally executed subsystems are executing. In simplified initialization mode, however, these outports will update the merge signal with zero value when their parent conditionally executed subsystems are executing. | |
| Warning: Merge Blocks Initial Output Value Can No Longer Be Specified By Signal Objects | Ensure that the following behavior is acceptable. The Initial output parameter of the Merge block cannot be specified by signal objects. You can initialize the input or output signals for a Merge block using signal objects, but the initialization results may be overwritten by that from the Merge block. | |
| Warning: Outport Blocks Will Obtain Initial Output Value from Input Signal When Migrated | Ensure that the following behavior is acceptable. The Initial output parameter of the Outport block is not specified. Simplified initialization mode will assume that the initial output value for the Outport block is derived from the input signal, which may result in different initialization behavior. | |
| Warning: Outer Outport Blocks With Explicit Initial Output | Ensure that the following behavior is acceptable. The Initial output and Output when disabled parameters of the Outport block are currently required to match those of their source Outport blocks. This constraint is not required in simplified initialization mode. However, this flexibility means that nested Outport blocks with explicit initial output values cannot share signal storage. You can regain this signal storage efficiency by setting Initial output to [] (empty matrix), and Output when disabled to held, so that the Outports derive their initial output value, and can therefore share signal storage with their input signals. | |
| Warning: Conditionally Executed Subsystems Propagating Execution Context Across Output Boundary | Ensure that the following behavior is acceptable. Propagate execution context across subsystem boundary is selected for the subsystem. Propagating execution context across an output boundary can cause unpredictable initialization behavior, and therefore is not supported in simplified initialization mode. Execution context will still be propagated across input boundaries. | |
| Warning: Initialization Behavior Changes for Discrete-Time Integrators | Ensure that the following behavior is acceptable. The initialization behavior of the Discrete-Time Integrator block has been changed to be more consistent and robust in simplified initialization mode. These changes include:
See the Discrete-Time Integrator block documentation for more information on simplified Discrete-Time Integrator initialization. | |
| Warning: Blocks Will Not Be Allowed To Read Input From Conditionally Executed Subsystems During Initialization | Ensure that the following behavior is acceptable. Some blocks, such as the Discrete-Time Integrator block, currently read their inputs from conditionally executed subsystems during initialization. This is done as an optimization. This optimization is not allowed in simplified initialization mode because the output of a conditionally executed subsystem at the first time step after initialization may be different than the initial value declared in the corresponding Outport block. In particular, this occurs if the subsystem is active at the first time step. | |
| Error: Library Blocks With Instances That Cannot Be Migrated | Examine the error messages for each block to determine a proper corrective action. | |
| Warning: Library Blocks With Instances That Have Warning Messages | Examine the warning messages for each block before migrating. | |
| Message: Outport Blocks Will Use Dialog Initial Output Value After Migration | No action required. The Outport block will maintain its current settings and use its specified Initial output value. | |
| Message: Outport Blocks Will Use Initial Output Value From Input Signal After Migration | No action required. The Outport block currently specifies an Initial output of [] (empty matrix), and Output when disabled as held. This means that each outport does not perform initialization, but implicitly relies on source blocks to initialize its input signal. After migration, the parameter Source of initial output value will be set to Input signal to reflect this behavior. | |
| Message: Outport Blocks To Use SimEvents Initialization Semantics | No action required. The Outport block will continue to use an Initial output of [] (empty matrix), and Output when disabled as held, because their parent conditionally executed subsystems are connected to SimEvents blocks. |
Merge block
Discrete-Time Integrator block
Outport block
Detect multiple driving blocks executing at the same time step
Identify Data Store blocks whose sample times cause modeling errors.
Multitasking Data Store blocks often indicate a modeling problem using Data Store blocks.
| Condition | Recommended Action |
|---|---|
| Data Store blocks in your model have continuous or zero-order-hold sample times. | Consider making the listed blocks discrete or replacing them with Memory or Goto and From blocks. |
| The compile time diagnostic Multitask data store is set to none. | Consider setting Multitask data store to warning or error in the Configuration Parameters > Diagnostics > Data Validity pane. |
Identify noncontinuous signals that drive derivative ports.
Noncontinuous signals that drive derivative ports cause the solver to reset every time the signal changes value, which slows down simulation.
| Condition | Recommended Action |
|---|---|
| There are noncontinuous signals in the model driving derivative ports. |
|
How Simulink Works in the Simulink documentation.
Verify that read and write order checking is on if there are Data Store blocks in the model.
Results are unpredictable if read and write order checking is off.
| Condition | Recommended Action |
|---|---|
| Detect read before write checking is disabled. | Consider enabling Detect read before write in the Configuration Parameters > Diagnostics > Data Validity pane. |
| Detect write after read checking is disabled. | Consider enabling Detect write after read in the Configuration Parameters > Diagnostics > Data Validity pane. |
| Detect write after write checking is disabled. | Consider enabling Detect write after write in the Configuration Parameters > Diagnostics > Data Validity pane. |
The runtime diagnostics might slow down simulations considerably. Set them to Disable all once you have verified that Simulink does not generate any warnings or errors during simulation.
Check array bounds and solver consistency if S-Function blocks are in the model.
Validates whether S-Function blocks adhere to the ODE solver consistency rules that Simulink applies to its built-in blocks.
| Condition | Recommended Action |
|---|---|
| Solver data inconsistency is set to none. | Set Solver data inconsistency in the Configuration Parameters > Diagnostics pane to warning or error. |
| Array bounds exceeded is set to none. | Set Array bounds exceeded in the Configuration Parameters > Diagnostics > Data Validity pane to warning or error |
Writing S-Functions in the Simulink documentation
 | Model Advisor Checks | Simulink Limits |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
