Documentation

Contents

Simulink Checks

Simulink Check Overview

Use the Simulink® Model Advisor checks to configure your model for simulation.

See Also

Identify unconnected lines, input ports, and output ports

Check for unconnected lines or ports.

Description

This check lists unconnected lines or ports. These can have difficulty propagating signal attributes such as data type, sample time, and dimensions.

    Note:   Ports connected to ground/terminator blocks will pass this test.

Results and Recommended Actions

ConditionRecommended Action
Lines, input ports, or output ports are unconnected.Connect the signals. Double-click the list of unconnected items to locate failure.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation™ license.

Tips

Use the PortConnectivity command to obtain an array of structures describing block input or output ports.

See Also

Common Block Properties for information on the PortConnectivity command.

What Is a Model Advisor Exclusion?

Check root model Inport block specifications

Check that root model Inport blocks fully define dimensions, sample time, and data type.

Description

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.

Results and Recommended Actions

ConditionRecommended Action
Root-level Inport blocks have undefined attributes.Fully define the attributes of the root-level Inport blocks.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Check optimization settings

Check for optimizations that can lead to nonoptimal code generation and simulation.

Description

This check reviews the status of optimizations that can improve code efficiency and simulation time.

Results and Recommended Actions

ConditionRecommended Action
The specified optimizations are off.

Select the following optimization check boxes on the Optimization pane in the Configuration Parameters dialog box:

Select the following optimization check boxes on the Optimization > Signals and Parameters pane in the Configuration Parameters dialog box:

Select the following optimization check boxes on the Optimization > Stateflow pane in the Configuration Parameters dialog box:

Application lifespan (days) is set as infinite. This could lead to expensive 64-bit counter usage. Choose a 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:
  • Diagnostics > Solver > Solver data inconsistency

  • Diagnostics > Data Validity > Array bounds exceeded

  • Diagnostics > Data Validity > Simulation range checking

The specified Embedded Coder® parameters are off.If you have a Embedded Coder license, and you are using an ERT-based system target file, select the following check boxes:

Tips

If the system contains Model blocks and the referenced model is in Accelerator mode, simulating the model requires generating and compiling code.

See Also

Check for parameter tunability information ignored for referenced models

Checks if parameter tunability information is included in the Model Parameter Configuration dialog box.

Description

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.

Results and Recommended Actions

ConditionRecommended Action
Model contains ignored parameter tunability information.Click the links to convert to equivalent Simulink parameter objects in the MATLAB® workspace.

See Also

Parameters.

Check for implicit signal resolution

Identify models that attempt to resolve named signals and states to Simulink.Signal objects.

Description

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.

Results and Recommended Actions

ConditionRecommended Action
Not all signals and states are resolved.Turn off implicit signal resolution and enforce resolution for each signal and state that does resolve.

See Also

Resolve Signal Objects for Output Data.

Check for optimal bus virtuality

Identify virtual buses that could be made nonvirtual. Making these buses nonvirtual improves generated code efficiency.

Description

This check identifies blocks incorporating virtual buses that cross a subsystem boundary. Changing these to nonvirtual improves generated code efficiency.

Results and Recommended Actions

ConditionRecommended Action
Blocks that specify a virtual bus crossing a subsystem boundary.Change the highlighted bus to nonvirtual.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

See Also

Check for Discrete-Time Integrator blocks with initial condition uncertainty

Identify Discrete-Time Integrator blocks with state ports and initial condition ports that are fed by neither an Initial Condition nor a Constant block.

Description

Discrete-Time Integrator blocks with state port and initial condition ports might not be suitably 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.

Results and Recommended Actions

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

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

See Also

Identify disabled library links

Search model for disabled library links.

Description

Disabled library links can cause unexpected simulation results. Resolve disabled links before saving a model.

Results and Recommended Actions

ConditionRecommended Action
Library links are disabled.Click the Library Link > Resolve link option in the context menu.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

Tips

  • 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. Select Library Link > Resolve link.

See Also

Restore Disabled or Parameterized Links.

What Is a Model Advisor Exclusion?

Identify parameterized library links

Search model for parameterized library links.

Description

Parameterized library links that are unintentional can result in unexpected parameter settings in your model. This can result in improper model operation.

Results and Recommended Actions

ConditionRecommended Action
Parameterized links are listed.Verify that the links are intended to be parameterized.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

Tips

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

See Also

Restore Disabled or Parameterized Links.

What Is a Model Advisor Exclusion?

Identify unresolved library links

Search the model for unresolved library links, where the specified library block cannot be found.

Description

Check for unresolved library links. Models do not simulate while there are unresolved library links.

Results and Recommended Actions

ConditionRecommended Action
Library links are unresolved.Locate missing library block or an alternative.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

See Also

Fix Unresolved Library Links

What Is a Model Advisor Exclusion?

Identify model reference variants and variant subsystems that override variant choice

Identify model or subsystem for model reference variants and variant subsystems that specify variant choice using the override option instead of using the active variant object.

Results and Recommended Actions

ConditionRecommended Action
Model reference variants or variant subsystems that override variant choice are identified.Specify variant choice using active variant object.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

See Also

Set and Open Active Variants

What Is a Model Advisor Exclusion?

Identify configurable subsystem blocks for converting to variant subsystem blocks

Search the model to identify configurable subsystem blocks at the model or subsystem level.

Results and Recommended Actions

ConditionRecommended Action
Configurable subsystem blocks are identified.Convert these blocks to variant subsystem blocks to avoid compatibility issues. See Convert Subsystem Blocks to Variant Subsystem Blocks

Capabilities and Limitations

You can run this check on your library models.

See Also

Set Up Model Variants

Check usage of function-call connections

Check model diagnostic settings that apply to function-call connectivity and that might impact model execution.

Description

Check for connectivity diagnostic settings that might lead to non-deterministic model execution.

Results and Recommended Actions

ConditionRecommended Action
Diagnostics > Connectivity > Invalid function-call connection is set to none or warning. This might lead to non-deterministic model execution.Set Diagnostics > Connectivity > Invalid function-call connection to error.
Diagnostic > Connectivity > Context-dependent inputs is set to Disable All or Use local settings. This might lead to non-deterministic model execution.Set Diagnostics > Connectivity > Context-dependent inputs to Enable all as errors.

See Also

Function-Call Subsystem

Check signal logging save format

Check signal logging save format.

Description

Check signal logging save format. The signal logging save format ModelDataLogs will be removed in a future release. To take advantage of new functionality, update models using ModelDataLogs format to use Dataset format.

Results and Recommended Actions

ConditionRecommended Action

The model has the signal logging format set to Dataset.

No action required.

The model has the signal logging format set to ModelDataLogs.

Use the Upgrade Advisor (with the upgradeadvisor function) to upgrade a model to use Dataset format. Enable the Check signal logging save format check, run the check, and click the Update format button.

The model contains Model blocks. Models in the model reference hierarchy require the same signal logging save format.

Use the Upgrade Advisor (with the upgradeadvisor function) to upgrade a model to use Dataset format. Enable the Check signal logging save format check, run the check, and click the Update format button.

See Also

Specify the Signal Logging Data Format

Check Data Store Memory blocks for multitasking, strong typing, and shadowing issues

Look for modeling issues related to Data Store Memory blocks.

Description

Checks for multitasking data integrity, strong typing, and shadowing of data stores of higher scope.

Results and Recommended Actions

ConditionRecommended Action
The Duplicate data store names check is set to none or warning. Consider setting the Duplicate data store names check to error in the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane.
The data store variable names are not strongly typed in one of the following:
  • Signal Attributes pane of the Block Parameters dialog for the Date Store Memory block

  • Global data store name

Specify a data type other than auto by taking one of the following actions:
  • Choose a data type other than Inherit: auto on the Signal Attributes pane of the Block Parameters dialog for the Date Store Memory block.

  • If you are using a global data store name, then specify its data type in the Simulink.Signal object.

The Multitask data store check is set to none or warning. Consider setting the Multitask data store check to error in the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Check if read/write diagnostics are enabled for data store blocks

For data store blocks in the model, enable the read-and-write diagnostics order checking to detect run-time issues.

Description

Check for the read-and-write diagnostics order checking. By enabling the read-and-write diagnostics, you detect potential run-time issues.

Results and Recommended Actions

ConditionRecommended Action
The Detect read before write check is disabled.Consider enabling Detect read before write in the Configuration Parameter dialog box Diagnostics> Data Validity pane.
The Detect write after read check is disabled.Consider enabling Detect write after read in the Configuration Parameter dialog box Diagnostics> Data Validity pane.
The Detect write after write check is disabled.Consider enabling Detect write after write in the Configuration Parameter dialog box Diagnostics> Data Validity pane.

Capabilities and Limitations

Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

Tips

.

  • The run-time diagnostics can slow simulations down considerably. Once you have verified that Simulink does not generate warnings or errors during simulation, set them to Disable all.

See Also

Check data store block sample times for modeling errors

Identify modeling errors due to the sample times of data store blocks.

Description

Check data store blocks for continuous or fixed-in-minor-step sample times.

Results and Recommended Actions

ConditionRecommended Action
Data store blocks in your model have continuous or fixed-in-minor-step sample times.Consider making the listed blocks discrete or replacing them with either Memory or Goto and From blocks.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Check for potential ordering issues involving data store access

Look for read/write issues which may cause inaccuracies in the results.

Description

During an Update Diagram, identify potential issues relating to read-before-write, write-after-read, and write-after-write conditions for data store blocks.

Results and Recommended Actions

ConditionRecommended Action
Reading and writing (read-before-write or write-after-read condition) occur out of order.Consider restructuring your model so that the Data Store Read block executes before the Data Store Write block.
Multiple writes occur within a single time step.Change the model to write data only once per time step or refer to the following Tips section.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

Tips

This check performs a static analysis which might not identify every instance of improper usage. Specifically, Function-Call Subsystems, Stateflow® Charts, MATLAB for code generation, For Iterator Subsystems, and For Each Subsystems can cause both missed detections and false positives. For a more comprehensive check, consider enabling the following diagnostics on the Diagnostics > Data Validity pane in the Configuration Parameters dialog box: Detect read before write, Detect write after read, and Detect write after write.

See Also

Check for partial structure parameter usage with bus signals

Identify blocks that use partial structures as parameter values for bus signals.

Description

This check compares structures that provide parameter values for bus signals, to identify partial structures. This check returns a table listing the:

  • Paths to blocks that use partial structures as parameter values for bus signals

  • Names the block parameters that use the partial structure

For all data stores that you define with a Simulink.Signal object that uses a partial structure for its Initial value parameter, this check lists the following information, in a second table:

  • Name of the signal object

  • Workspace (MATLAB or model) of the signal object

  • Name of the signal object parameter that uses the partial structure

Results and Recommended Actions

ConditionRecommended Action

Block using partial structure

Consider using the Simulink.Bus.createMATLABStructure function to convert a partial structure parameter to a full structure of parameter values for the listed blocks.

Signal objects using partial structure

Consider using the Simulink.Bus.createMATLABStructure function to convert a partial structure parameter to a full structure of parameter values for the listed signals.

Tips

  • Specifying partial structures for block parameter values can be useful during the iterative process of creating a model. You can use partial structures to focus on a subset of signals in a bus.

  • Specifying full structures for code generation offers these advantages:

    • Generated code is more readable than the code generated for partial structures.

    • Supports a modeling style that explicitly initializes unspecified signals. When you use partial structures, Simulink initializes unspecified signals implicitly.

See Also

Check Unit Delay and Zero-Order Hold blocks for rate transition

Identify Unit Delay or Zero-Order Hold blocks that are used for rate transition. Replace these blocks with actual Rate Transition blocks.

Description

If a model uses Unit Delay or Zero-Order Hold blocks to provide rate transition between input and output signals, Simulink makes a hidden replacement of these blocks with built-in Rate Transition blocks. In the compiled block diagram, a yellow symbol and the letters "RT" appear in the upper-left corner of a replacement block. This replacement can affect the behavior of the model, as follows:

  • These blocks lose their algorithmic design properties to delay a signal or implement zero-order hold. Instead, they acquire rate transition behavior.

  • This modeling technique works only in specific transition configurations (slow-to-fast for Unit Delay and fast-to-slow for Zero-Order Hold block). Set the block sample time to be equal to the slower rate (source for the Unit Delay block and destination for the Zero-Order Hold block).

  • When the block sample time of a downstream or upstream block changes, these Unit Delay and Zero-Order Hold blocks might not perform rate transition. For example, setting the source and destination sample times equal stops rate transition. The blocks then assume their original algorithmic design properties.

  • The block sample time shows incomplete information about sample time rates. The block code runs at two different rates to handle data transfer. However, the block sample time and sample time color show it as a single-rate block. Tools and MATLAB scripts that use sample time information base their behavior on this information.

An alternative is to replace Unit Delay or Zero-Order Hold blocks with actual Rate Transition blocks.

  • The technique ensures unambiguous results in block behavior. Unit Delay or Zero-Order Hold blocks act according to their algorithmic design to delay and hold signals respectively. Only Rate Transition blocks perform actual rate transition.

  • Using an actual Rate Transition block for rate transition offers a configurable solution to handle data transfer if you want to specify deterministic behavior or the type of memory buffers to implement.

Use this check to identify instances in your model where Unit Delay or Zero-Order Hold blocks undergo hidden replacement to provide rate transition between signals. Click Upgrade Model to replace these blocks with actual Rate Transition blocks.

Results and Recommended Actions

ConditionRecommended Action
Model has no instances of Unit Delay or Zero-Order Hold blocks used for rate transition.No action required.
Model has instances of Unit Delay or Zero-Order Hold blocks used for rate transition. The check identifies these instances and allows you to upgrade the model.
  1. Click Upgrade Model to replace with actual Rate Transition blocks.

  2. Save changes to your model.

If you do not choose to replace the Unit Delay and/or Zero-Order Hold blocks with actual Rate Transition blocks, Simulink continues to perform a hidden replacement of these blocks with built-in rate transition blocks.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

See Also

Check for calls to slDataTypeAndScale

Identify calls to the internal function slDataTypeAndScale.

Description

In some previous versions of Simulink, opening a model that had been saved in an earlier version triggers an automatic upgrade to code for data type handling. The automatic upgrade inserts calls to the internal function slDataTypeAndScale. Although Simulink continues to support some uses of the function, if you eliminate calls to it, you get cleaner and faster code.

Simulink does not support calls to slDataTypeAndScale when:

  • The first argument is a Simulink.AliasType object.

  • The first argument is a Simulink.NumericType object with property IsAlias set to true.

Running Check for calls to slDataTypeAndScale identifies calls to slDataTypeAndScale that are required or recommended for replacement. In most cases, running the check and following the recommended action removes the calls. You can ignore calls that remain. Run the check unless you are sure there are not calls to slDataTypeAndScale.

Results and Recommended Actions

ConditionRecommended Action
Required Replacement CasesManually or automatically replace calls to slDataTypeAndScale. Cases listed require you to replace calls to slDataTypeAndScale.
Recommended Replacement CasesFor the listed cases, it is recommended that you manually or automatically replace calls to slDataTypeAndScale.
Manual Inspection CasesInspect each listed case to determine whether it should be manually upgraded.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

Tips

  • Do not manually insert a call to slDataTypeAndScale into a model. The function was for internal use only.

  • Running Check for calls to slDataTypeAndScale calls the Simulink function slRemoveDataTypeAndScale. Calling this function directly provides a wider range of conversion options. However, you very rarely need more conversion options.

See Also

  • For more information about upgrading data types and scales, in the MATLAB Command Window, execute the following:

    • help slDataTypeAndScale

    • help slRemoveDataTypeAndScale

  • What Is a Model Advisor Exclusion?

Check bus usage

Identify Mux blocks used as a bus creator and bus signal that Simulink treats as a vector.

Description

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

Results and Recommended Actions

ConditionRecommended Action

Model uses Mux blocks to create bus signals.

Replace Mux blocks with Bus Creator blocks.

Model is not configured to identify Mux blocks used as bus creators.

In the Configuration Parameters dialog box, on the Diagnostics > Connectivity pane, set Mux blocks used to create bus signals to error.

Bus signals are implicitly converted to vectors.

Use Simulink.BlockDiagram.addBusToVector or insert a Bus to Vector block.

Model is not configured to identify bus signals Simulink treats as vectors.

In the Configuration Parameters dialog box, on the Diagnostics > Connectivity pane, set Bus signal treated as vector to error.

Action Results

Clicking Modify causes one of the following:

  • Replace Mux blocks with Bus Creator blocks.

  • Insert a Bus to Vector block at the input ports of blocks that implicitly convert bus signals to vectors.

Tips

  • The Bus to Vector conversion block resides in the Simulink/Signal Attributes library.

  • Run this check before running Check consistency of initialization parameters for Outport and Merge blocks.

  • The Non-bus signals treated as bus signals diagnostic detects when Simulink implicitly converts a non-bus signal to a bus signal to support connecting the signal to a Bus Assignment or Bus Selector block. This diagnostic is in the Configuration Parameters dialog box, on the Diagnostics> Connectivity pane.

See Also

Check for potentially delayed function-call subsystem return values

Identify function-call return values that might be delayed because Simulink software inserted an implicit Signal Conversion block.

Description

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

Results and Recommended Actions

ConditionRecommended 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.
  • If the delay is not acceptable, rework your model so that the input signal originates from within the calling subsystem.

  • If the delay is acceptable, insert a Unit Delay block in front of each listed input port.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Signal Conversion block

Unit Delay block

What Is a Model Advisor Exclusion?

Identify block output signals with continuous sample time and non-floating point data type

Find continuous sample time, non-floating-point output signals.

Description

Non-floating-point signals might not represent continuous variables without loss of information.

Results and Recommended Actions

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

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

What Is Sample Time?.

What Is a Model Advisor Exclusion?

Check usage of Merge blocks

Analyze Merge blocks in the same tree as a group, and determine the possibility for them to execute at the same time step.

Description

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.

Input Parameters

Maximum analysis time (seconds)

Provide a maximum analysis time to execute the check.

Results and Recommended Actions

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

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Check consistency of initialization parameters for Outport and Merge blocks

Identify Outport and Merge blocks with parameter settings that can lead to unexpected initialization behavior, and migrate your model to the simplified initialization mode.

Description

In R2008b or later versions, you can choose the simplified initialization mode for conditionally executed subsystems, Merge blocks, subsystem elapsed time, and Discrete-Time Integrator blocks. The simplified initialization mode improves the consistency of simulation results. This result is especially true 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. For more information, see Address Classic Mode Issues by Using Simplified Mode.

    Note:   Before running this consistency check, verify that your block diagram conforms to the modeling standards set by this diagnostic.

    1. Run Check bus usage in the Model Advisor to check your usage of Mux blocks.

    2. In the model window, select Simulation >
      Model Configuration Parameters
      >
      Diagnostics
      > Connectivity.

    3. Set Mux blocks used to create bus signals to error and click OK.

    For more information, see Diagnostics Pane: Connectivity.

This Model Advisor check identifies settings in your model that can cause problems if you use the simplified initialization mode. The results of the subchecks contain two types of statements: Failed and Warning. Failed statements identify issues that you must address manually before you can migrate the model to the simplified initialization mode. Warning statements identify issues or changes in behavior that may occur after migration.

After running this Model Advisor consistency check, if you select the Explore Result button, then the messages will only pertain to blocks that are not library-linked blocks.

    Note:   Because it is difficult to undo these changes, use the Save Restore Point As feature to back up your model before migrating to the simplified initialization mode.

Results and Recommended Actions

ConditionRecommended Action
Check the run-time diagnostic setting of the Merge block.
  1. In the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane, set Detect multiple driving blocks executing at the same time step to error.

  2. Verify that the model simulates without errors before running this check again.

Verify that all Model blocks are using the simplified initialization mode.Migrate the model referenced by the Model block to the simplified initialization mode, then migrate the top model.
Check for Model blocks that are using the PIL simulation mode.The simplified initialization mode does not support the Processor-in-the-loop (PIL) simulation for model references.
Check for 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 the simplified initialization mode.

Check for root Merge blocks that have an unspecified Initial output value.

If you do not specify an explicit value for the Initial output parameter of root Merge blocks, then Simulink uses the default initial value of the output data type.

A root Merge block is a Merge block with an output port that does not connect to another Merge block. For information on the default initial value, see Initializing Signal Values.

Check for Merge blocks with nonzero input port offsets.Clear the Allow unequal port widths parameter of the Merge block.

    Note:   Consider using Merge blocks only for signal elements that require true merging. You can combine other elements with merged elements using the Concatenate block.

Check for Merge blocks that have unconnected inputs or that have inputs from non-conditionally executed subsystems.Set the Number of inputs parameter of the Merge block to the number of Merge block inputs. You must connect each input to a signal.

Verify that each Merge block input is driven by a conditionally executed subsystem. Merge blocks cannot be driven directly by an Iterator Subsystem or a block that is not a conditionally executed subsystem.

Check for Merge blocks with inputs that are combined or reordered outside of conditionally executed subsystems.Verify that any combination or reordering of Merge block input signals takes place within a conditionally executed subsystem. Such designs may use Mux, Bus Creator, or Selector blocks.
Check for Merge blocks with inconsistent input sample times.

Verify that input signals to each Merge block have the same Sample time.

Failure to do so could result in unpredictable behavior. Consequently, the simplified initialization mode does not allow inconsistent sample times.

Check for Merge blocks with multiple input ports that are driven by a single source.Verify that the Merge block does not have multiple input signals that are driven by the same conditionally executed subsystem or conditionally executed Model block.
Check for Outport blocks that have conflicting signal buffer requirements.

The Outport block has a function-call trigger or function-call data dependency signal passing through it, along with standard data signals. Some of the standard data signals require an explicit signal buffer for the initialization of the output signal of the corresponding subsystem. However, buffering function-call related signals leads to a function-call data dependency violation.

Consider modifying the model to pass function-call related signals through a separate Outport block. For examples of function-call data dependency violations, see the example model sl_subsys_semantics.

A standard data signal may require an additional signal copy for one of the following reasons:

  • The Outport block is driven by a block with output that cannot be overwritten. The Ground block and the Constant block are examples of such blocks.

  • The Outport block shares the same signal source with another Outport block in the same subsystem or in one nested within the current subsystem but having a different initial output value.

  • The Outport block connects to the input of a Merge block

  • One of the input signals of the Outport block is specifying a Simulink.Signal object with an explicit initial value .

Check for Outport blocks that are driven by a bus signal and whose Initial output value is not scalar.For Outport blocks driven by bus signals, classic initialization mode does not support Initial Condition (IC) structures, while simplified initialization mode does. Hence, when migrating a model from classic to simplified mode, specify a scalar for the Initial Output parameter. After migration completes, to specify different initial values for different elements of the bus signal, use IC structures. For more information, see Create Initial Condition (IC) Structures.
Check for Outport blocks that require an explicit signal copy.An explicit copy of the bus signal driving the Outport block is required for the initialization of the output signal of the corresponding subsystem.

Insert a Signal Conversion block before the Outport block, then set the Output parameter of the Signal Conversion block to Bus copy.

A standard data signal may require an additional signal copy for one or more of the following reasons:

  • A block with output that cannot be overwritten is driving the Outport block. The Ground block and the Constant block are examples of such blocks.

  • The Outport block shares the same signal source with another Outport block in the same subsystem or in one nested within the current subsystem but having a different initial output value.

  • The Outport block connects to the input of a Merge block

  • One of the input signals of the Outport block is specifying a Simulink.Signal object with an explicit initial value.

Check for merged Outport blocks that inherit the Initial Output value from Outport blocks that have been configured to reset when the blocks become disabled.When Outport blocks are driving a Merge block, do not set their Output when disabled parameters to reset.
Check for merged Outport blocks that are driven by nested conditionally executed subsystems.Determine if the new behavior of the Outport blocks is acceptable. If it is not acceptable, modify the model to account for the new behavior before migrating to the simplified initialization mode.
Check for merged Outport blocks that reset when the blocks are disabled.

Set the Output when disabled parameter of the Outport block to held. This setting is required because the Outport block connects to a Merge block.

For more information, see Outport.

Check for Outport blocks that have an undefined Initial output value with invalid initial condition sources.

Verify that the following behavior is acceptable.

When the Initial output parameter is unspecified ([]), it inherits the initial output from the source blocks. If at least one of the sources of the Outport block is not a valid source to inherit the initial value, the block uses the default initial value for that data type.

For simplified initialization mode, valid sources an Outport blocks can inherit the Initial output value from are: Constant, Initial Condition, Merge (with initial output), Stateflow chart, function-call model reference, or conditionally executed subsystem blocks.

Check Outport blocks that have automatic rate transitions.

Simulink has inserted a Rate Transition block at the input of the Outport block. Specify the Initial output parameter for each Outport block.

Otherwise, perform the following procedure:

  1. In the Configuration Parameters dialog box, on the Solver pane, clear the option Automatically handle rate transition for data transfer.

  2. Run this Model Advisor check again.

Check Outport blocks that have a special signal storage requirement and have an undefined Initial output value.

Verify that the following behavior is acceptable.

Specify the Initial output parameter for the Outport block. Set this value to [] (empty matrix) to use the default initial value of the output data type.

Check the 'Initial output' setting of Outport blocks that reset when they are disabled.

Specify the Initial output parameter of the Outport block.

You must specify the Initial output value for blocks that are configured to reset when they become disabled.

Check the 'Initial output' setting for Outport blocks that pass through a function-call data dependency signal.

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:

  1. Set the Initial output parameter of the Outport block to [].

  2. Provide the initial value at the source of the data dependency signal rather than at the Outport block.

Check for blocks inside of the Iterator Subsystem that require elapsed time.

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 an Iterator Subsystem can execute multiple times at a given time step, the concept of elapsed time is not well-defined between two such executions. Using these blocks inside of an Iterator Subsystem can cause unexpected behavior.

Check for Outport blocks that use signal objects to specify the Initial output value.

Verify that the following behavior is acceptable.

In the simplified initialization mode, signal objects cannot specify the Initial output parameter of an Outport block. You can still initialize the input or output signals for an Outport block using signal objects, but the initialization results may be overwritten by those of the Outport block.

    Note:   If you are working with a conditionally executed subsystem Outport block, Simulink generates a warning that the initial value of the signal object has been ignored.

Check for merged Outport blocks that are either unconnected or connected to a Ground block.

Verify 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 the classic initialization mode, unconnected or grounded outports do not update the merge signal even when their parent conditionally executed subsystems are executing. In the simplified initialization mode, however, these outports will update the merge signal with a value of zero when their parent conditionally executed subsystems are executing.

Check for Merge blocks that use signal objects to specify the Initial output value.

Verify that the following behavior is acceptable.

In the simplified initialization mode, signal objects cannot specify the Initial output parameter of the Merge block. While you can still initialize the output signal for a Merge block using a signal object, the initialization result may be overwritten by that of the Merge block.

    Note:   Simulink generates a warning that the initial value of the signal object has been ignored.

Check for Outport blocks that obtain the Initial output value from an input signal when they are migrated.

Verify that the following behavior is acceptable.

The Initial output parameter of the Outport block is not specified. As a result, the simplified initialization mode will assume that the Initial output value for the Outport block is derived from the input signal. This assumption may result in different initialization behavior.

If this behavior is not acceptable, modify your model before you migrate to the simplified initialization mode.

Check for outer Outport blocks that have an explicit Initial output.

Verify that the following behavior is acceptable.

In classic initialization mode, the Initial output and Output when disabled parameters of the Outport block must match those of their source Outport blocks.

In simplified initialization mode, Simulink sets the Initial output parameter to [] (empty matrix) and Output when disabled parameter to held.

Check for conditionally executed subsystems that propagate execution context across the output boundary.

Verify that the following behavior is acceptable.

The Propagate execution context across subsystem boundary parameter is selected for the subsystem. Execution context will still be propagated across input boundaries; however, the propagation will be disabled on the output side for the initialization in the simplified initialization mode.

Check for blocks that read input from conditionally executed subsystems during initialization.

Verify that the following behavior is acceptable.

Some blocks, such as the Discrete-Time Integrator block, read their inputs from conditionally executed subsystems during initialization in the classic initialization mode. Simulink performs this step as an optimization technique.

This optimization is not allowed in the 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 discrepancy occurs if the subsystem is active at the first time step.

Check for library blocks with instances that cannot be migrated.Examine the failed subcheck results for each block to determine the corrective actions.
Check for library blocks with instances that have warnings.Examine the warning subcheck results for each block before migrating to the simplified initialization mode.
Check for a migration conflict for Outport blocks that use a Dialog as the Source of initial output value.

Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block.

The Outport block will maintain its current settings and use its specified Initial output value.

Check for a migration conflict for Outport blocks that use Input signal as the Source of initial output value.

Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block.

The Outport block currently specifies an Initial output of [] (empty matrix), and the 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.

Check for a migration conflict for Outport blocks that have SimEvents semantics.

Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block.

The Outport blocks will continue to use an Initial output value of [] (empty matrix) and an Output when disabled setting of held. Simulink will maintain these settings because their parent conditionally executed subsystems are connected to SimEvents® blocks.

Check for a migration conflict for innermost Outport blocks with variable-size input and unspecified Initial output.

For these Outport blocks, the signal size varies only when the parent subsystem of the block is re-enabled. Therefore, Simulink implicitly assumes that the Initial output parameter is equal to 0, even though the parameter is unspecified, []. Consequently, unless you specify the parameter, the Model Advisor will explicitly set the parameter to 0 when the model is migrated to the simplified initialization mode.

Other instances of Outport blocks with the same library link either cannot be migrated or are being migrated in a different manner. Review the results from the Check for library blocks with instances that cannot be migrated to learn about the different migration paths for other instances of each Outport block.

Check for a migration conflict for Outport blocks that use a default ground value as the Initial output.The parameter Initial output is set to [] (empty matrix) and the source of the Outport is an invalid initial condition source. Thus, the block uses the default initial value as the initial output in the simplified initialization mode. Other instances of Outport blocks with the same library link either have errors or are being migrated differently.
Check for a migration conflict for merged Outport blocks without explicit specification of Initial output.Review the results from the subcheck Check for library blocks with instances that cannot be migrated to learn about different migration paths for other instances of each Outport block. For the remaining Outport blocks, Initial output is set to [] (empty matrix) and Output when disabled is set to held respectively, in simplified initialization mode.

Action Results

Clicking Modify Settings causes the following:

  • The Model parameter is set to simplified

  • If an Outport block has the Initial output parameter set to the empty string , [] , then the SourceOfInitialOutputValue parameter is set to Input signal.

  • If an Outport has an empty Initial output and a variable-size signal, then the Initial output is set to zero.

See Also

Check for non-continuous signals driving derivative ports

Identify noncontinuous signals that drive derivative ports.

Description

Noncontinuous signals that drive derivative ports cause the solver to reset every time the signal changes value, which slows down simulation.

Results and Recommended Actions

ConditionRecommended Action
There are noncontinuous signals in the model driving derivative ports.
  • Make the specified signals continuous.

  • Replace the continuous blocks receiving these signals with discrete state versions of the blocks.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Runtime diagnostics for S-functions

Check array bounds and solver consistency if S-Function blocks are in the model.

Description

Validates whether S-Function blocks adhere to the ODE solver consistency rules that Simulink applies to its built-in blocks.

Results and Recommended Actions

ConditionRecommended Action
Solver data inconsistency is set to none.In the Configuration Parameters dialog box, on the Diagnostics pane, set Solver data inconsistency to warning or error.
Array bounds exceeded is set to none.In the Configuration Parameters dialog box, on the Diagnostics> Data Validity pane, set Array bounds exceeded to warning or error

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Check model for foreign characters

Check for characters that are incompatible with the current encoding

Description

Check for characters in the model file that cannot be represented in the current encoding. These can cause errors during simulation, and may be corrupted when saving the model.

Results and Recommended Actions

ConditionRecommended Action
Incompatible characters foundChange the current encoding to the encoding specified in the model file, using slCharacterEncoding. To change the current encoding you need to close the models, and this closes the Model Advisor.

Tips

The Upgrade Advisor report shows the encoding you need, or you can retrieve the encoding from the model using the command:

get_param(modelname,'SavedCharacterEncoding')

Use slCharacterEncoding to change the encoding. This setting applies to the current MATLAB session, so if you restart MATLAB and want to open the same model, you will need to make the same change to the current encoding again.

For more information see:

See Also

Check model for known block upgrade issues

Check for common block upgrade issues.

Description

Check blocks in the model for compatibility issues resulting from using a new version of Simulink software.

Results and Recommended Actions

ConditionRecommended Action
Blocks with compatibility issues found.Click Modify to fix the detected block issues.
Check update status for the Level 2 API S-functions.Consider replacing Level 1 S-functions with Level 2.

Action Results

Clicking Modify replaces blocks from a previous release of Simulink software with the latest versions.

See Also

Check model for known block upgrade issues requiring compile time information

Check for common block upgrade issues.

Description

Check blocks for compatibility issues resulting from upgrading to a new version of Simulink software. Some block upgrades require the collection of information or data when the model is in the compile mode. For this check, the model is set to compiled mode and then checked for upgrades.

Results and Recommended Actions

ConditionRecommended Action
Model contains Lookup Table or Lookup Table (2-D) blocks and some of the blocks specify Use Input Nearest or Use Input Above for a lookup method.Replace Lookup Table blocks and Lookup Table (2-D) blocks with n-D Lookup Table blocks. Do not apply Use Input Nearest or Use Input Above for lookup methods; select another option.
Model contains Lookup Table or Lookup Table (2-D) blocks and some blocks perform multiplication first during interpolation.Replace Lookup Table blocks and Lookup Table (2-D) blocks with n-D Lookup Table blocks. However, because the n-D Lookup Table block performs division first, this replacement might cause a numerical difference in the result.
Model contains Lookup Table or Lookup Table (2-D) blocks. Some of these blocks specify Interpolation-Extrapolation as the Lookup method but their input and output are not the same floating-point type.Replace Lookup Table blocks and Lookup Table (2-D) blocks with n-D Lookup Table blocks. Then change the extrapolation method or the port data types for block replacement.

Action Results

Clicking Modify replaces blocks from a previous release of Simulink software with the latest versions.

See Also

Check that the model is saved in SLX format

Check that the model is saved in SLX format.

Description

Check whether the model is saved in SLX format.

Results and Recommended Actions

ConditionRecommended Action
Model not saved in SLX formatConsider upgrading to the SLX file format to use the latest features in Simulink.

Capabilities and Limitations

You can run this check on your library models.

Tips

Simulink Projects can help you upgrade models to SLX format and preserve file revision history in source control. See Upgrade Model Files to SLX and Preserve Revision History.

See Also

Check Model History properties

Check for edited model history properties

Description

Check models for edited Model History property values that could be used with source control tool keyword substitution. This keyword substitution is incompatible with SLX file format.

In the MDL file format you can configure some model properties to make use of source control tool keyword substitution. If you save your model in SLX format, source control tools cannot perform keyword substitution. Information in the model file from such keyword substitution is cached when you first save the MDL file as SLX, and is not updated again. The Model Properties History pane and Model Info blocks in your model show stale information from then on.

Results and Recommended Actions

ConditionRecommended Action
Edited model history propertiesManually or automatically reset the properties to the default values. Click the button to reset, or to inspect and change these properties manually, open the Model Properties dialog and look in the History pane.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check for Mux blocks used to create bus signals

Identify Mux blocks used as a bus creator.

Description

Models cannot contain Mux blocks that output bus signals. Instead, replace those Mux blocks with Bus Creator blocks.

Results and Recommended Actions

ConditionRecommended Action

Model uses Mux blocks to create bus signals.

Replace Mux blocks with Bus Creator blocks.

Model is not configured to identify Mux blocks used as bus creators.

In the Configuration Parameters dialog box, on the Diagnostics > Connectivity pane, set Mux blocks used to create bus signals to error.

Action Results

Clicking Modify replaces Mux blocks with Bus Creator blocks.

Tip

The Non-bus signals treated as bus signals diagnostic detects when Simulink implicitly converts a non-bus signal to a bus signal to support connecting the signal to a Bus Assignment or Bus Selector block. This diagnostic is in the Configuration Parameters dialog box, on the Diagnostics> Connectivity pane.

See Also

Check model for legacy 3DoF or 6DoF blocks

Lists 3DoF and 6DoF blocks are outdated.

Description

This check searches for 3DoF and 6DoF blocks from library versions prior to 3.13 (R2014a).

Results and Recommended Actions

ConditionRecommended Action
Blocks configured with old versions of 3DoF or 6DoF blocks found.Click Replace 3DoF and 6DoF Blocks to replace the blocks with latest versions.

Action Results

Clicking Replace 3DoF and 6DoF Blocks replaces blocks with the latest versions.

See Also

Check model and local libraries for legacy Aerospace Blockset blocks

Lists blocks configured to use FlightGear versions that are outdated or not supported.

Description

This check searches and lists blocks configured to use FlightGear versions that are outdated or not supported.

Results and Recommended Actions

ConditionRecommended Action
Blocks configured with old versions of FlightGear are found.Click Update FlightGear blocks to change block settings to latest supported version of FlightGear. Then, download latest version of FlightGear that MATLAB supports.

Action Results

Clicking Update FlightGear blocks changes block settings to the latest supported version of FlightGear.

See Also

Check and update masked blocks in library to use promoted parameters

Check for libraries that should be updated to use promoted parameters.

Description

This check searches libraries created before R2011b for masked blocks that should be updated to use promoted parameters. Since R2011b, if a block parameter is not promoted, its value in the linked block is locked to its value in the library block. This check excludes blocks of type Subsystem, Model reference, S-Function and M-S-Function.

Results and Recommended Actions

ConditionRecommended Action
Libraries that need to be updated are foundClick Update. Once the libraries have been updated, run the check again

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

See Also

Check and update mask image display commands with unnecessary imread() function calls

Check identifies masks using image display commands with unnecessary calls to the imread() function.

Description

This check searches for the mask display commands that make unnecessary calls to the imread() function, and updates them with mask display commands that do not call the imread() function. Since 2013a, a performance and memory optimization is available for mask images specified using the image path instead of the RGB triple matrix.

Results and Recommended Actions

ConditionRecommended Action
Mask display commands that make unnecessary calls to the imread() function are found.Click Update. Once the blocks have been updated, run the check again.

Capabilities and Limitations

You can:

  • Run this check on your library models.

  • Exclude blocks and charts from this check if you have a Simulink Verification and Validation license.

See Also

Identify masked blocks that specify tabs in mask dialog using MaskTabNames parameter

This check identifies masked blocks that specify tabs in mask dialog using the MaskTabNames parameter.

Description

This check identifies masked blocks that use the MaskTabNames parameter to programmatically create tabs in the mask dialog. Since R2013b, dialog controls are used to group parameters in a tab on the mask dialog.

Results and Recommended Actions

ConditionRecommended Action
Masked blocks commands that use the MaskTabNames parameter to programmatically create tabs in the mask dialog are found.Click Upgrade. Once the blocks have been updated, run the check again.

Capabilities and Limitations

You can run this check on your library models.

See Also

Identify questionable operations for strict single-precision design

For a strict single-precision design, this check identifies the blocks that introduce double-precision operations.

Description

For a strict single-precision design, this check identifies the blocks that introduce double-precision operations.

Results and Recommended Actions

ConditionRecommended Action
Double-precision floating-point operations found in model. Verify that:
  • Block input and output data types are set correctly.

  • In the Configuration Parameters dialog box, on the Optimization pane, Default for underspecified data type is set to single.

  • All target-specific math libraries used by the model support single-precision implementations.

Capabilities and Limitations

If you have a Simulink Verification and Validation license, you can exclude blocks and charts from this check.

See Also

Check get_param calls for block CompiledSampleTime

Use this check to identify MATLAB files in your working environment that contain get_param function calls to return the block CompiledSampleTime parameter.

Description

For multi-rate blocks (including subsystems), Simulink returns the block compiled sample time as a cell array of the sample rates in the block. The return value is a cell array of pairs of doubles. MATLAB code that accepts this return value only as pairs of doubles can return an error when called with a multi-rate block. Use this check to identify such code in your environment. Modify these instances of code to accept a cell array of pairs of doubles instead.

For example, consider a variable blkTs, which has been assigned the compiled sample time of a multi-rate block.

blkTs = get_param(block,'CompiledSampleTime');

Here are some examples in which the original code works only if blkTs is a pair of doubles and the block is a single-rate block:

  • Example 1

    if isinf(blkTs(1))
        disp('found constant sample time')
    end
    

    Since blkTs is now a cell array, Simulink gives this error message:

    Undefined function 'isinf' for input arguments of type 'cell'

    Instead, use this code, for which blkTs can be a cell array or a pair of doubles.

    if isequal(blkTs, [inf,0])
        disp('found constant sample time')
    end
    
  • Example 2

    if all(blkTs == [-1,-1])
        disp('found triggered sample time')
    end
    

    For the above example, since blkTs is now a cell array, Simulink gives this error:

    Undefined function 'eq' for input arguments of type 'cell'

    Instead, use this code, for which blkTs can be a cell array or a pair of doubles.

    if isequal(blkTs, [-1,-1])
        disp('found triggered sample time')
    end
  • Example 3

    if (blkTs(1) == -1)
        disp('found a triggered context')
    end

    Again, since blkTs is now a cell array, Simulink gives this error:

    Undefined function 'eq' for input arguments of type 'cell'

    Instead, use this code.

    if ~iscell(blkTs)
        blkTs = {blkTs};
    end
    for idx = 1:length(blkTs)
        thisTs = blkTs{idx};
        if (thisTs(1) == -1)
            disp('found a triggered context')
        end
    end

    The above code checks for a triggered type sample time (triggered or async). In cases in which a block has constant sample time ([inf,0]) in addition to triggered or async or when a block has multiple async rates, this alternative property detects the triggered type sample time.

This check scans MATLAB files in your environment. If the check finds instances of MATLAB code that contain get_param calls to output the block compiled sample time, Upgrade Advisor displays these results. It suggests that you modify code that accepts the block compiled sample time from multi-rate blocks.

Results and Recommended Actions

ConditionRecommended Action
No MATLAB files call get_param(block,CompiledSampleTime)None
Some MATLAB files call get_param(block,CompiledSampleTime)If files use the block CompiledSampleTime parameter from multi-rate blocks, modify these files to accept the parameter as a cell array of pairs of doubles.

See Also

Check Rapid Accelerator signal logging

When simulating your model in Rapid Accelerator mode, use this check to find signals logged in your model that are globally disabled. Rapid Accelerator mode supports signal logging. Use this check to enable signal logging globally.

Description

This check scans your model to see if a simulation is in Rapid Accelerator mode and whether the model contains signals with signal logging. If the check finds an instance and signal logging is globally disabled, an option to turn on signal logging globally appears.

Results and Recommended Actions

ConditionRecommended Action

Simulation mode is not Rapid Accelerator.

None You can enable signal logging in Rapid Accelerator mode.

Simulation mode is Rapid Accelerator. Upgrade Advisor did not find signals with signal logging enabled.

NoneThe model does not use signal logging. Enable signal logging for signals and globally if you want to log signals.

Simulation mode is Rapid Accelerator. Upgrade Advisor found signals with signal logging enabled. However, global setting for signal logging was disabled.

Enable signal logging globally if you want to log signals with signal logging enabled.

Signal logging was already globally enabled.

None

Action Results

Selecting Modify enables signal logging globally in your model.

See Also

Check for root outports with constant sample time

Use this check to identify root outports with a constant sample time used with an AUTOSAR target, Function Prototype Control, or the model C++ class interface.

Description

Root outports with constant sample time are not supported when using an AUTOSAR target, Function Prototype Control, or the model C++ class interface. Use this check to identify root Outport blocks with this condition and modify the blocks as recommended.

Results and Recommended Actions

ConditionRecommended Action
Root outport with constant sample time used with an AUTOSAR target, Function Prototype Control or the model C++ class interface.Consider one of the following:
  • Set the sample time of the block to the fundamental sample time.

  • Identify the source of the constant sample time and set its sample time to the fundamental sample time.

  • Place a Rate Transition block with inherited sample time (-1) before the block.

See Also

Analyze model hierarchy and continue upgrade sequence

Check for child models and guide you through upgrade checks.

Description

This check identifies child models of this model, and guides you through upgrade checks to run both non-compile and compile checks. The Advisor provides tools to help with these tasks:

  • If the check finds child models, it offers to run the Upgrade Advisor upon each child model in turn and continue the upgrade sequence. If you have a model hierarchy you need to check and update each child model in turn.

  • If there are no child models, you still need to continue the check sequence until you have run both non-compile and compile checks.

You must run upgrade checks in this order: first the checks that do not require compile time information and do not trigger an Update Diagram, then the compile checks.

Click Continue Upgrade Sequence to run the next checks. If there are child models, this will open the next model. Keep clicking Continue Upgrade Sequence until the check passes.

Results and Recommended Actions

ConditionRecommended Action
Child models foundClick Continue Upgrade Sequence to run the next checks. If there are child models, this will close the current Upgrade Advisor session, and open Upgrade Advisor for the next model in the hierarchy.
No child models, but more checks to runIf there are no child models, click Continue Upgrade Sequence to refresh the Upgrade Advisor with compilation checks selected. The compile checks trigger an Update Diagram (marked with ^). Run the next checks and take advised actions. When you return to this check, click Continue Upgrade Sequence until this check passes.

Tips

Best practice for upgrading a model hierarchy is to check and upgrade each model starting at the leaf end and working up to the root model.

When you click Continue Upgrade Sequence, the Upgrade Advisor opens the leaf model as far inside the hierarchy as it can find. Subsequent steps guide you through upgrading your hierarchy from leaf to root model.

When you open the Upgrade Advisor, the checks that are selected do not require compile time information and do not trigger an Update Diagram. Checks that trigger an Update Diagram are not selected to run by default, and are marked with ^. When you use the Upgrade Advisor on a hierarchy, keep clicking Continue Upgrade Sequence to move through this sequence of analysis:

  1. The Upgrade Advisor opens each model and library in turn, from leaf to root, and selects the non-compile checks. Run the checks, take any advised actions, then click Continue Upgrade Sequence to open the next model and continue.

  2. When you reach the root end of the hierarchy, the Upgrade Advisor then opens each model again in the same order (but not libraries) and selects only the checks that require a model compile. Run the checks, take any advised actions, then click Continue Upgrade Sequence to open the next model. Continue until you reach the end of the hierarchy and this check passes.

See Also

Was this topic helpful?