Contents

Ports & Subsystems

hisl_0006: Usage of While Iterator blocks

ID: Titlehisl_0006: Usage of While Iterator blocks
DescriptionTo support bounded iterative behavior in the generated code when using the While Iterator block, in the While Iterator block parameters dialog box:
A

Set Maximum number of iterations to a positive integer value; do not set value to —1 for unlimited.

B

Consider selecting Show iteration number port to observe the iteration value during simulation.

Note

When you use While Iterator subsystems, set the maximum number of iterations. If you use an unlimited number of iterations, the generated code might include infinite loops, which lead to execution-time overruns.

To observe the iteration value during simulation and determine whether the loop reaches the maximum number of iterations, select the While Iterator block parameter Show iteration number port. If the loop reaches the maximum number of iterations, verify the output values of the While Iterator block.

RationaleA, BSupport bounded iterative in the generated code.
Model Advisor Checks
References
  • IEC 61508-3, Table A.3 (3) 'Language subset'
    IEC 61508-3, Table A.4 (3) 'Defensive programming'

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

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

  • DO-331, Section MB.6.3.1.e 'High-level requirements conform to standards'
    DO-331, Section MB.6.3.2.e 'Low-level requirements conform to standards'

  • MISRA-C:2004, Rule 21.1

Last ChangedR2013b

hisl_0007: Usage of While Iterator subsystems

ID: Titlehisl_0007: Usage of While Iterator subsystems
DescriptionTo support unambiguous behavior, when using While Iterator subsystems,
A

Specify inherited (-1) or constant (inf) sample times for the blocks within the subsystems.

B

Avoid using sample time-dependent blocks, such as integrators, filters, and transfer functions, within the subsystems.

RationaleA, BAvoid ambiguous behavior from the subsystem.
Model Advisor Checks
References
  • IEC 61508-3, Table A.3 (3) 'Language subset'
    IEC 61508-3, Table A.4 (3) 'Defensive programming'

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

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

  • DO-331, Section MB.6.3.1.e 'High-level requirements conform to standards'
    DO-331, Section MB.6.3.2.e 'Low-level requirements conform to standards'

  • MISRA-C:2004, Rule 21.1

Last ChangedR2013b
Examples

For iterative subsystems, the value delta T is nonzero for the first iteration only. For subsequent iterations, the value is zero.

In the following example, in the output of the Sum block calculation that uses the unit delay, the Sum block calculation does not require delta T. The output of the Discrete-Time Integrator block displays the result of having a zero delta T value.

hisl_0008: Usage of For Iterator Blocks

ID: Titlehisl_0008: Usage of For Iterator blocks
Description

To support bounded iterative behavior in the generated code when using the For Iterator block, do one of the following:

A

In the For Iterator block parameters dialog box, set Iteration limit source to internal.

B

If Iteration limit source must be external, use a block that has a constant value, such as a Width, Probe, or Constant.

C

In the For Iterator block parameters dialog box, clear Set next i (iteration variable) externally.

D

In the For Iterator block parameters dialog box, consider selecting Show iteration variable to observe the iteration value during simulation.

Notes

When you use the For Iterator block, feed the loop control variable with fixed (nonvariable) values to get a predictable number of loop iterations. Otherwise, a loop can result in unpredictable execution times and, in the case of external iteration variables, infinite loops that can lead to execution-time overruns.

RationaleA, B, C, DSupport bounded iterative behavior in generated code.
Model Advisor Checks
References
  • IEC 61508-3, Table A.3 (3) 'Language subset'
    IEC 61508-3, Table A.4 (3) 'Defensive programming'

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

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

  • DO-331, MB.Section 6.3.1.e 'High-level requirements conform to standards'
    DO-331, Section MB.6.3.2.e 'Low-level requirements conform to standards'

  • MISRA-C:2004, Rule 13.6

Last ChangedR2013b

hisl_0009: Usage of For Iterator Subsystem blocks

ID: Titlehisl_0009: Usage of For Iterator Subsystem blocks
Description

To support unambiguous behavior, when using the For Iterator Subsystem block,

A

Specify inherited (-1) or constant (inf) sample times for blocks within the subsystem.

B

Avoid using sample time-dependent blocks, such as integrators, filters, and transfer functions, within the subsystem.

RationaleA, BAvoid ambiguous behavior from the subsystem.
Model Advisor Checks
References
  • IEC 61508-3, Table A.3 (3) 'Language subset';
    IEC 61508-3, Table A.4 (3) 'Defensive programming'

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

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

  • DO-331, Section MB.6.3.2.g 'Algorithms are accurate'

  • MISRA-C:2004, Rule 13.6

Last ChangedR2013b
Examples

See hisl_0007: Usage of While Iterator subsystems.

hisl_0010: Usage of If blocks and If Action Subsystem blocks

ID: Titlehisl_0010: Usage of If blocks and If Action Subsystem blocks
Description

To support verifiable generated code, when using the If block with nonempty Elseif expressions,

A

In the block parameter dialog box, select Show else condition.

B

Connect the outports of the If block to If Action Subsystem blocks.

Prerequisites

hisl_0016: Usage of blocks that compute relational operators

Notes

The combination of If and If Action Subsystem blocks enable conditional execution based on input conditions. When there is only an if branch, you do not need to include an else branch.

RationaleA, BSupport generation of verifiable code.
References
  • IEC 61508-3, Table A.3 (3) 'Language subset'
    IEC 61508-3, Table A.4 (3) 'Defensive programming'

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

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

  • MISRA-C:2004, Rule 14.10

See Alsona_0012: Use of Switch vs. If-Then-Else Action Subsystem in the Simulink® documentation
Last ChangedR2013b
Examples

Recommended: Elseif with Else

Not Recommended: No Else Path

Recommended: Only an If, no Else required

hisl_0011: Usage of Switch Case blocks and Action Subsystem blocks

ID: Titlehisl_0011: Usage of Switch Case blocks and Action Subsystem blocks
Description

To support verifiable generated code, when using the Switch Case block:

A

In the Switch Case block parameter dialog box, select Show default case.

B

Connect the outports of the Switch Case block to a Switch Case Action Subsystem block.

C

Use an integer data type or an enumeration value for the inputs to Switch Case blocks.

Prerequisites

hisl_0016: Usage of blocks that compute relational operators

Notes

The combination of Switch Case and If Action Subsystem blocks enable conditional execution based on input conditions. Provide a default path of execution in the form of a "Default" block.

RationaleA, B, CSupport generation of verifiable code.
References
  • IEC 61508-3, Table A.3 (3) 'Language subset'
    IEC 61508-3, Table A.4 (3) 'Defensive programming'

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

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

  • MISRA-C:2004, Rule 15.3

See Also

db_0115: Simulink patterns for case constructs in the Simulink documentation.

Last ChangedR2014b
Examples

The following graphic displays an example of providing a default path of execution using a "Default" block.

hisl_0012: Usage of conditionally executed subsystems

ID: Titlehisl_0012: Usage of conditionally executed subsystems
Description

To support unambiguous behavior, when using conditionally executed subsystems:

A

Specify inherited (-1) sample times for all blocks in the subsystem, except Constant. Constant blocks can use infinite (inf) sample time.

B

If the subsystem is called asynchronously, avoid using sample time-dependent blocks, such as integrators, filters, and transfer functions, within the subsystem.

Notes

Conditionally executed subsystems include:

  • If Action

  • Switch Case Action

  • Function-Call

  • Triggered

  • Enabled

Sample time-dependent blocks include:

  • Discrete State-Space

  • Discrete-Time Integrator

  • Discrete FIR Filter

  • Discrete Filter

  • Discrete Transfer Fcn

  • Discrete Zero-Pole

  • Transfer Fcn First Order

  • Transfer Fnc Real Zero

  • Transfer Fcn Lead or Lag

RationaleA, BSupport unambiguous behavior.
References
  • IEC 61508-3, Table A.3 (3) 'Language subset'
    IEC 61508-3, Table A.4 (3) 'Defensive programming'

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

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

Last ChangedR2013b
ExamplesWhen using discrete blocks, the behavior depends on the operation across multiple contiguous time steps. When the blocks are called intermittently, the results may not conform to your expectations.

hisl_0024: Inport interface definition

ID: Titlehisl_0024: Inport interface definition
DescriptionTo support strong data typing and unambiguous behavior of the model and the generated code, for each root-level Inport block, explicitly set the following block parameters:
  • Data type

  • Port dimensions

  • Sample time

NoteUsing root-level Inport blocks without fully defined dimensions, sample times, or data type can lead to ambiguous simulation results. If you do not explicitly define these parameters, Simulink back-propagates dimensions, sample times, and data types from downstream blocks.
Rationale
  • Avoid unambiguous behavior.

  • Support full specification of software interface.

Model Advisor Checks
References
  • 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‘

Last ChangedR2014b

hisl_0025: Design min/max specification of input interfaces

ID: Titlehisl_0025: Design min/max specification of input interfaces
DescriptionProvide design min/max information for root-level Inport blocks to specify the input interface ranges.
Notes
  • Specifying the range of Inport blocks on the root level enables additional capabilities[a]. Examples include:

    • Detection of overflows through simulation range checking.

    • Code optimizations using Embedded Coder®.

    • Design model verification using Simulink Design Verifier™.

    • Fixed-point autoscaling using Fixed-Point Designer™.

  • Specified design ranges can be used by Embedded Coder to optimize the generated code. If you want to use design ranges for optimization, in the Configuration Parameters dialog box, on the Code Generation pane, consider selecting Optimize using the specified minimum and maximum values.

  • Ranges for bus-type Inport blocks are specified with the bus elements of the defining bus object. Simulink ignores range specifications provided directly at Inport blocks that are bus-type.

Rationale

Support precise specification of the input interface.

Model Advisor Checks
References
  • IEC 61508-3, Table B.9 (5) ‘Fully defined interface'

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

  • EN 50128, Table A.1(11) – Software Interface Specifications, Table A.3 (19) ‘Fully Defined Interface‘

Last ChangedR2013b

[a] These capabilities leverage design range information for different purposes. For more information, refer to the documentation for the tools you intend to use.

hisl_0026: Design min/max specification of output interfaces

ID: Titlehisl_0026: Design min/max specification of output interfaces
DescriptionProvide design min/max information for root-level Outport blocks to specify the output interface ranges.
Notes
  • Specifying the range of Outport blocks on the root level enables additional capabilities[a]. Examples include:

    • Detection of overflows through simulation range checking.

    • Code optimizations using Embedded Coder.

    • Design model verification using Simulink Design Verifier.

    • Fixed-point autoscaling using Fixed-Point Designer.

  • Specified design ranges can be used by Embedded Coder to optimize the generated code. If you want to use design ranges for optimization, in the Configuration Parameters dialog box, on the Code Generation pane, consider selecting Optimize using the specified minimum and maximum values.

  • Ranges for bus-type Outport blocks are specified with the bus elements of the defining bus object. Simulink ignores range specifications provided directly at Outport blocks that are bus-type.

Rationale

Support precise specification of the output interface.

Model Advisor Checks
References
  • IEC 61508-3, Table B.9 (5) ‘Fully defined interface'

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

  • EN 50128, Table A.1(11) – Software Interface Specifications, Table A.3 (19) ‘Fully Defined Interface‘

Last ChangedR2013b

[a] These capabilities leverage design range information for different purposes. For more information, refer to the documentation for the tools you intend to use.

Was this topic helpful?