Documentation Center

  • Trials
  • Product Updates

Contents

IEC 61508, ISO 26262, and EN 50128 Checks

IEC 61508, ISO 26262, and EN 50128 Checks Overview

IEC 61508, ISO 26262, and EN 50128 checks facilitate designing and troubleshooting models, subsystems, and the corresponding generated code for applications to comply with IEC 61508-3, ISO 26262-6, or EN 50128.

The Model Advisor performs a checkout of the Simulink® Verification and Validation™ license when you run the IEC 61508, ISO 26262, or EN 50128 checks.

Tips

If your model uses model referencing, run the IEC 61508, ISO 26262, or EN 50128 checks on all referenced models before running them on the top-level model.

See Also

  • IEC 61508-3 Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements

  • ISO 26262-6 Road vehicles - Functional safety - Part 6: Product development: Software level

  • EN 50128 Railway applications - Communications, signalling and processing systems - Software for railway control and protection systems

  • Embedded Coder® documentation:

Display model metrics and complexity report

Display number of elements and name, level, and depth of subsystems for the model or subsystem.

Description

The IEC 61508, ISO 26262, and EN 50128 standards recommend the usage of size and complexity metrics to assess the software under development. This check provides metrics information for the model. The provided information can be used to inspect whether the size or complexity of the model or subsystem exceeds given limits. The check displays:

  • A block count for each Simulink block type contained in the given model.

  • The maximum subsystem depth of the given model.

  • A count of Stateflow® constructs in the given model (if applicable).

  • Name, level, and depth of the subsystems contained in the given model (if applicable).

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
N/A This summary is provided for your information. No action is required.

Capabilities and Limitations

You can run this check on your library models.

See Also

  • IEC 61508-3, Table A.9 (5) - Software complexity metrics

  • ISO 26262-6, Table 1 (1a) - Enforcement of low complexity, Table 4 (1a) - Hierarchical structure of software components, Table 4 (1b) - Restricted size of software components, and Table 4 (1c) - Restricted size of interfaces

  • EN 50128, Table A.12 (8) - Limited size and complexity of Functions, Subroutines and Methods and (9) Limited number of subroutine parameters

  • sldiagnostics in the Simulink documentation

  • Cyclomatic Complexity in the Simulink Verification and Validation documentation

Check for unconnected objects

Identify unconnected lines, input ports, and output ports in the model.

Description

Unconnected objects are likely to cause problems propagating signal attributes such as data, type, sample time, and dimensions.

Ports connected to Ground or Terminator blocks pass this check.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
There are unconnected lines, input ports, or output ports in the model or subsystem.
  • Double-click an element in the list of unconnected items to locate the item in the model diagram.

  • Connect the objects identified in the results.

Capabilities and Limitations

You can run this check on your library models.

See Also

  • IEC 61508-3, Table A.3 (3) - Language subset

  • ISO 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1d) - Use of defensive implementation techniques

  • EN 50128, Table A.4 (11) - Language Subset

  • Signal Basics

Check for root Inports with missing properties

Identify root model Inport blocks with missing or inherited sample times, data types or port dimensions.

Description

Using root model Inport blocks that do not have defined sample time, data types or port dimensions can lead to undesired simulation results. Simulink back-propagates dimensions, sample times, and data types from downstream blocks unless you explicitly assign these values. When you run the check, a results table provides links to Inport blocks that do not pass, along with conditions triggering the warning.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action

Missing port dimension — Model contains Inport blocks with inherited port dimensions.

For the listed Inport blocks, specify port dimensions.

Missing signal data type — Model contains Inport blocks with inherited data types.

For the listed Inport blocks, specify data types.

Missing port sample time — Model contains Inport blocks with inherited sample times.

For the listed Inport blocks, specify sample times. The sample times for root Inports with bus type must match the sample times specified at the leaf elements of the bus object.

Tips

The following configuration passes this check:

  • Inport blocks with inherited sample times in conjunction with the Periodic sample time constraint menu set to Ensure sample time independent

See Also

  • IEC 61508-3, Table B.9 (5) - Fully defined interface

  • ISO 26262-4, Table 2 (2) - Precisely defined interfaces

  • ISO 26262-6, Table 1 (1f) - Use of unambiguous graphical representation

  • EN 50128, Table A.3 (19) - Fully Defined Interface

  • Data Types in the Simulink documentation

  • Determine Output Signal Dimensions in the Simulink documentation

  • Specify Sample Time in the Simulink documentation

Check for MATLAB Function block interfaces with inherited properties

Identify MATLAB® Function blocks that have inputs, outputs or parameters with inherited complexity or data type properties.

Description

The check identifies MATLAB Function blocks with inherited complexity or data type properties. A results table provides links to MATLAB Function blocks that do not pass the check, along with conditions triggering the warning.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
MATLAB Function blocks have inherited interfaces.

Explicitly define complexity and data type properties for inports, outports, and parameters of MATLAB Function block identified in the results.

If applicable, using the MATLAB Function Block Editor, make the following modifications in the Ports and Data Manager:

  • Change Complexity from Inherited to On or Off.

  • Change Type from Inherit: Same as Simulink to an explicit type.

In the results table, Compiled Value provides suggestions for the actual values after the model compiles. If a MATLAB Function block is defined within a library, explicitly define the interface in the library rather than in the referencing model. If your model has multiple instances of MATLAB Function blocks defined in a library block, and the instances have different interface properties, consider using multiple library blocks.

See Also

Check MATLAB Function block metrics

Display complexity and code metrics for MATLAB Function blocks and external MATLAB functions. Report metric violations.

Description

The IEC 61508, ISO 26262, and EN 50128 standards recommend the usage of size and complexity metrics to assess the software under development. This check provides complexity and code metrics for MATLAB Function blocks and external MATLAB functions. The check additionally reports metric violations.

A results table provides links to MATLAB Function blocks and external MATLAB functions that violate the complexity input parameters.

Available with Simulink Verification and Validation.

Input Parameters

Maximum effective lines of code per function

Provide the maximum effective lines of code per function. Effective lines do not include empty lines, comment lines, or lines with a function end keyword.

Minimum density of comments

Provide minimum density of comments. Density is ratio of comment lines to total lines of code.

Maximum cyclomatic complexity per function

Provide maximum cyclomatic complexity per function. Cyclomatic complexity is the number of linearly independent paths through the source code.

Results and Recommended Actions

ConditionRecommended Action
MATLAB Function blocks or external MATLAB functions violate the complexity input parameters.For the MATLAB Function block or external MATLAB function:
  • If effective lines of code is too high, further divide the MATLAB function.

  • If comment density is too low, add comment lines.

  • If cyclomatic complexity per function is too high, further divide the MATLAB function.

See Also

Check for root Inports with missing range definitions

Identify root level Inport blocks with missing or erroneous minimum or maximum range values.

Description

The check identifies root level Inport blocks with missing or erroneous minimum or maximum range values. To have a precise and static definition of the interface range, you should specify the range at the Inport. A results table provides links to Inport blocks that do not pass the check, along with conditions triggering the warning.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action

Missing range at Inport — Model contains Inport blocks with numeric data types that have missing range parameters (minimum and/or maximum).

Specify scalar minimum and maximum parameters for the listed Inport blocks.

Missing range(s) at bus object — Bus objects defining the Inport blocks have leaf elements with missing ranges.

To specify the model interface range, provide scalar minimum and maximum parameters for the listed leaf elements.

Range specified at Inport will be ignored — Minimum or maximum values at Inports are not supported for bus data types. The values are ignored during range checking.

To enable range checking, specify minimum and maximum signal values on the leaf elements of the bus objects defining the data type.

To enable the use of minimum and maximum values with bus objects, set configuration parameter Diagnostics > Connectivity > Buses > Mux blocks used to create bus signals to error.

No data type specified — Model contains Inport blocks with no data type specified.

Specify a supported data type.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check for root Outports with missing range definitions

Identify root level Outport blocks with missing or erroneous minimum or maximum range values.

Description

The check identifies root level Outport blocks with missing or erroneous minimum or maximum range values. To have a precise and static definition of the interface range, you should specify the range at the Outport. A results table provides links to Outport blocks that do not pass the check, along with conditions triggering the warning.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action

Missing range at Outport — Model contains Outport blocks with numeric data types that have missing range parameters (minimum and/or maximum).

Specify scalar minimum and maximum parameters for the listed Outport blocks.

Missing range(s) at bus object — Bus objects defining the Outport blocks have leaf elements with missing ranges.

To specify the model interface range, provide scalar minimum and maximum parameters for the listed leaf elements.

Range specified at Outport will be ignored — Minimum or maximum values at Outports are not supported for bus data types. The values are ignored during range checking.

To enable range checking, specify minimum and maximum signal values on the leaf elements of the bus objects defining the data type.

To enable the use of minimum and maximum values with bus objects, set configuration parameter Diagnostics > Connectivity > Buses > Mux blocks used to create bus signals to error.

No bus data type specified — Outport blocks have a bus signals entering with no bus data type specified.

Provide a bus object for the Outport block data type.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check for blocks not recommended for C/C++ production code deployment

Identify blocks not supported by code generation or not recommended for C/C++ production code deployment.

Description

This check partially identifies model constructs that are not recommended for C/C++ production code generation as identified in the Simulink Block SupportSimulink Block Support tables for Simulink Coder™ and Embedded Coder. If you are using blocks with support notes for code generation, review the information and follow the given advice.

Available with Simulink Verification and Validation and Embedded Coder.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains blocks that should not be used for production code deployment.Consider replacing the blocks listed in the results. Click an element from the list of questionable items to locate condition.

Capabilities and Limitations

You can run this check on your library models.

See Also

  • IEC 61508-3, Table A.3 (3) - Language subset

  • ISO 26262-6, Table 1 (1b) - Use of language subsets

  • EN 50128, Table A.4 (11) - Language Subset

  • Supported Products and Block Usage

Check usage of Stateflow constructs

Identify usage of Stateflow constructs that might impact safety.

Description

This check identifies instances of Stateflow software being used in a way that can impact an application's safety, including:

  • Use of strong data typing

  • Port name mismatches

  • Scope of data objects and events

  • Formatting of state action statements

  • Ordering of states and transitions

  • Unreachable code

  • Indeterminate execution time

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
A Stateflow chart is not configured for strong data typing on boundaries between a Simulink model and the Stateflow chart. See:In the Chart properties dialog box, select Use Strong Data Typing with Simulink I/O for the Stateflow chart. When you select this check box, the Stateflow chart accepts input signals of any data type that Simulink models support, provided that the type of the input signal matches the type of the corresponding Stateflow input data object.
Signals have names that differ from those of their corresponding Stateflow ports. See:
  • IEC 61508-3, Table A.3 (3) - Language subset

  • ISO 26262-6, Table 1 (1b) - Use of language subsets

  • EN 50128, Table A.4 (11) - Language Subset

  • Check whether the ports are connected and, if not, fix the connections.

  • Change the names of the signals or the Stateflow ports so that the names match.

Local data is not defined in the Stateflow hierarchy at the chart level or below. See:
  • IEC 61508-3, Table A.3 (3) - Language subset

  • ISO 26262-6, Table 1 (1b) - Use of language subsets

  • EN 50128, Table A.4 (11) - Language Subset

Define local data at the chart level or below.

A new line is missing from a state action after:

  • An entry (en), during (du), or exit (ex) statement

  • The semicolon (;) at the end of an assignment statement

See:
  • IEC 61508-3, Table A.3 (3) - Language subset

  • ISO 26262-6, Table 1 (1b) - Use of language subsets

  • EN 50128, Table A.4 (11) - Language Subset

Add missing new lines.
Stateflow charts have User specified state/transition execution order cleared. See: For the specified charts, in the Chart Properties dialog box, select User specified state/transition execution order.
Any of the following debugging options are cleared:
  • Enable debugging/animation

  • Enable overflow detection (with debugging)

  • Transition Conflict

  • Data Range

  • Detect Cycles

See:
  • hisf_0011: Stateflow debugging settings

  • IEC 61508-3, Table A.7 (2) - Simulation/modeling

  • ISO 26262-6, Table 1 (1d) - Use of defensive implementation techniques

  • EN 50128, Table A.3 (1) - Defensive Programming, Table A.11 (13) Simulation

Select the debugging options.

In the Configuration Parameters dialog box, select:

  • Simulation Target > General > Enable debugging/animation

  • Simulation Target > General > Enable overflow detection (with debugging)

In the Stateflow Debugging dialog box, select:

  • Transition Conflict

  • Data Range

  • Detect Cycles

The Stateflow chart contains a data object identifier defined in two or more scopes. See:
  • hisl_0061: Unique identifiers for clarity

  • IEC 61508-3, Table A.3 (3) - Language subset, Table A.4 (5) - Design and coding standards

  • ISO 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1e) - Use of established design principles, Table 1 (1h) - Use of naming conventions

  • EN 50128, Table A.4 (11) - Language Subset, Table A.12 (1) - Coding Standard, Table A.12 (2) - Coding Style Guide

  • MISRA-C:2004, Rule 5.6

For the identified chart, do one of the following:
  • Create a unique data object identifier within each of the scopes.

  • Create a unique data object identifier within the chart, at the parent level.

Capabilities and Limitations

This check does not support charts that use MATLAB as the action language.

See Also

See the following topics in the Stateflow documentation:

Check state machine type of Stateflow charts

Identify whether Stateflow charts are all Mealy or all Moore charts.

Description

Compares the state machine type of all Stateflow charts to the type that you specify in the input parameters.

Available with Simulink Verification and Validation.

Input Parameters

Mealy or Moore

Check whether charts use the same state machine type, and are all Mealy or all Moore charts.

Mealy

Check whether all charts are Mealy charts.

Moore

Check whether all charts are Moore charts.

Results and Recommended Actions

ConditionRecommended Action
The input parameter is set to Mealy or Moore and charts in the model use either of the following:
  • Classic state machine types.

  • Multiple state machine types.

For each chart, in the Chart Properties dialog box, specify State Machine Type to either Mealy or Moore. Use the same state machine type for all charts in the model.
The input parameter is set to Mealy and charts in the model use other state machine types.For each chart, in the Chart Properties dialog box, specify State Machine Type to Mealy.
The input parameter is set to Moore and charts in the model use other state machine types.For each chart, in the Chart Properties dialog box, specify State Machine Type to Moore.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check for model objects that do not link to requirements

Check whether Simulink blocks and Stateflow objects link to a requirements document.

Description

This check verifies whether Simulink blocks and Stateflow objects link to a document containing engineering requirements for traceability.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Blocks do not link to a requirements document.Link to requirements document. See Link to Requirements Document Using Selection-Based Linking.

Capabilities and Limitations

  • You can run this check on your library models.

  • When you run this check, the Model Advisor does not follow library links or look under masks.

Tip

Run this check from the top model or subsystem that you want to check.

See Also

  • IEC 61508-3, Table A.1 (1) - Computer-aided specification tools, Table A.2 (8) - Computer-aided specification tools, Table A.8 (1) - Impact analysis

  • ISO 26262-6, Table 8 (1a) - Documentation of the software unit design in natural language

  • EN 50128, Table A.3 (23) - Modeling supported by computer aided design and specification tools, Table A.10 (1) - Impact Analysis

  • Requirements Traceability

Check for inconsistent vector indexing methods

Identify blocks with inconsistent indexing method.

Description

Using inconsistent block indexing methods can result in modeling errors. You should use a consistent vector indexing method for all blocks. This check identifies blocks with inconsistent indexing methods. The indexing methods are zero-based, one-based or user-specified.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains blocks with inconsistent indexing methods. The indexing methods are zero-based, one-based or user-specified.Modify the model to use a single consistent indexing method.

Capabilities and Limitations

You can run this check on your library models.

See Also

  • IEC 61508–3, Table A.3 (3) - Language subset, Table A.4 (5) - Design and coding standards

  • ISO 26262-6, Table 1 (b) - Use of language subsets, Table 1 (f) - Use of unambiguous graphical representation

  • EN 50128, Table A.4 (11) - Language Subset, Table A.12 (1) - Coding Standard

  • hisl_0021: Consistent vector indexing method

Check MATLAB Code Analyzer messages

Check MATLAB Functions for %#codegen directive, MATLAB Code Analyzer messages, and justification message IDs.

Description

Verifies %#codegen directive, MATLAB Code Analyzer messages, and justification message IDs for:

  • MATLAB code in MATLAB Function blocks

  • MATLAB functions defined in Stateflow charts

  • Called MATLAB functions

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
For MATLAB code in MATLAB Function blocks, either of the following:
  • Code lines are not justified with a %#ok comment.

  • Codes lines justified with %#ok do not specify a message id.

  • Implement MATLAB Code Analyzer recommendations.

  • Justify not following MATLAB Code Analyzer recommendations with a %#ok comment.

  • Specify justified code lines with a message id. For example, %#ok<NOPRT>.

For MATLAB functions defined in Stateflow charts, either of the following:
  • Code lines are not justified with a %#ok comment.

  • Codes lines justified with %#ok do not specify a message id.

  • Implement MATLAB Code Analyzer recommendations.

  • Justify not following MATLAB Code Analyzer recommendations with a %#ok comment.

  • Specify justified code lines with a message id. For example, %#ok<NOPRT>.

For called MATLAB functions:
  • Code does not have the %#codegen directive.

  • Code lines are not justified with a %#ok comment.

  • Codes lines justified with %#ok do not specify a message id.

  • Insert %#codegen directive in the MATLAB code.

  • Implement MATLAB Code Analyzer recommendations.

  • Justify not following MATLAB Code Analyzer recommendations with a %#ok comment.

  • Specify justified code lines with a message id. For example, %#ok<NOPRT>.

See Also

Check MATLAB code for global variables

Check for global variables in MATLAB code.

Description

Verifies that global variables are not used in any of the following:

  • MATLAB code in MATLAB Function blocks

  • MATLAB functions defined in Stateflow charts

  • Called MATLAB functions

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Global variables are used in one or more of the following:
  • MATLAB code in MATLAB Function blocks

  • MATLAB functions defined in Stateflow charts

  • Called MATLAB functions

Replace global variables with signal lines, function arguments, or persistent data.

See Also

Check usage of Math Operations blocks

Identify usage of Math Operation blocks that might impact safety.

Description

This check inspects the usage of the following blocks:

  • Abs

  • Assignment

  • Gain

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains an Absolute Value block that is operating on one of the following:
  • A boolean or an unsigned input data type. This condition results in unreachable simulation pathways through the model and might result in unreachable code

  • A signed integer value with the Saturate on integer overflow check box not selected. For signed data types, the absolute value of the most negative value is problematic because it is not representable by the data type. This condition results in an overflow in the generated code.

If the identified Absolute Value block is operating on a boolean or unsigned data type, do one of the following:

  • Change the input of the Absolute Value block to a signed input type.

  • Remove the Absolute Value block from the model.

If the identified Absolute Value block is operating on a signed data type, in the Block Parameters > Signal Attributes dialog box, select Saturate on integer overflow.

The model or subsystem contains Gain blocks with a of value 1.If you are using Gain blocks as buffers, consider replacing them with Signal Conversion blocks.
The model or subsystem might contain Assignment blocks with incomplete array initialization that do not have block parameter Action if any output element is not assigned set to Error.

When using the Assignment block with incompleted array initialization, set block parameter Action if any output element is not assigned to Error.

See Also

  • IEC 61508-3, Table A.3 (3) – Language subset, IEC 61508-3, Table A.4 (3) – Defensive programming, Table B.8 (3) – Control Flow Analysis

  • ISO 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1d) - Use of defensive implementation techniques, Table 7 (1f) - Control flow analysis

  • EN 50128, Table A.4 (11) - Language Subset, Table A.3 (1) - Defensive Programming, Table A.19 (3) - Control Flow Analysis

  • MISRA-C:2004, Rule 14.1

  • MISRA-C:2004, Rule 21.1

  • hisl_0001: Usage of Abs block

  • hisl_0029: Usage of Assignment blocks

Check usage of Signal Routing blocks

Identify usage of Signal Routing blocks that might impact safety.

Description

This check identifies model or subsystem Switch blocks that might generate code with inequality operations (~=) in expressions that contain a floating-point variable or constant.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains a Switch block that might generate code with inequality operations (~=) in expressions where at least one side of the expression contains a floating-point variable or constant. The Switch block might cause floating-point inequality comparisons in the generated code.

For the identified block, do one of the following:

  • For the control input block, change the Data type parameter setting.

  • Change the Switch block Criteria for passing first input parameter setting. This might change the algorithm.

See Also

  • IEC 61508-3, Table A.3 (3) – Language subset, Table A.4 (3) – Defensive programming

  • ISO 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1d) - Use of defensive implementation techniques

  • EN 50128, Table A.4 (11) - Language Subset, Table A.3 (1) - Defensive Programming

  • MISRA-C:2004, Rule 13.3

Check usage of Logic and Bit Operations blocks

Identify usage of Logical Operator and Bit Operations blocks that might impact safety.

Description

This check inspects the usage of:

  • Blocks that compute relational operators, including Relational Operator, Compare To Constant, Compare To Zero, and Detect Change blocks

  • Logical Operator blocks

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains a block computing a relational operator that is operating on different data types. The condition can lead to unpredictable results in the generated code. On the Block Parameters > Signal Attributes pane, set the Output data type to boolean for the specified blocks.
The model or subsystem contains a block computing a relational operator that uses the == or ~= operator to compare floating-point signals. The use of these operators on floating-point signals is unreliable and unpredictable because of floating-point precision issues. These operators can lead to unpredictable results in the generated code.

For the identified block, do one of the following:

  • Change the signal data type.

  • Rework the model to eliminate using == or ~= operators on floating-point signals.

The model or subsystem contains a Logical Operator block that has inputs or outputs that are not Boolean inputs or outputs. The block might result in floating-point equality or inequality comparisons in the generated code.
  • Modify the Logical Operator block so that the inputs and outputs are Boolean. On the Block Parameters > Signal Attributes pane, consider selecting Require all inputs to have the same data type and setting Output data type to boolean.

  • In the Configuration Parameters dialog box, on the Optimization pane, consider selecting the Implement logic signals as boolean data (vs. double).

See Also

Check usage of Ports and Subsystems blocks

Identify usage of Ports and Subsystems blocks that might impact safety.

Description

This check inspects the usage of:

  • For Iterator blocks

  • While Iterator blocks

  • If blocks

  • Switch Case blocks

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains a For Iterator block that has variable iterations. This condition can lead to unpredictable execution times or infinite loops in the generated code.For the identified For Iterator blocks, do one of the following:
  • Set the Iteration limit source parameter to internal.

  • If the Iteration limit source parameter must be external, use a Constant, Probe, or Width block as the source.

  • Clear the Set next i (iteration variable) externally check box.

  • Consider selecting the Show iteration variable check box and observe the iteration value during simulation.

The model or subsystem contains a While Iterator block that has unlimited iterations. This condition can lead to infinite loops in the generated code. For the identified While Iterator blocks:
  • Set the Maximum number of iterations (-1 for unlimited) parameter to a positive integer value.

  • Consider selecting the Show iteration number port check box and observe the iteration value during simulation.

The model or subsystem contains an If block with an If expression or Elseif expressions that might cause floating-point equality or inequality comparisons in generated code.Modify the expressions in the If block to avoid floating-point equality or inequality comparisons in generated code.
The model or subsystem contains an If block using Elseif expressions without an Else condition.In the If block Block Parameters dialog box, select Show else condition. Connect the resulting Else output port to an If Action Subsystem block.
The model or subsystem contains an If block with output ports that do not connect to If Action Subsystem blocks.Verify that output ports of the If block connect to If Action Subsystem blocks.
The model or subsystem contains an Switch Case block without a default case.In the Switch Case block Block Parameters dialog box, select Show default case. Connect the resulting default output port to a Switch Case Action Subsystem block.
The model or subsystem contains a Switch Case block with an output port that does not connect to a Switch Case Action Subsystem block.Verify that output ports of the Switch Case blocks connect to Switch Case Action Subsystem blocks.

See Also

Display configuration management data

Display model configuration and checksum information.

Description

This informer check displays the following information for the current model:

  • Model version number

  • Model author

  • Date

  • Model checksum

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Could not retrieve model version and checksum information. This summary is provided for your information. No action is required.

See Also

Was this topic helpful?