Main Content

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, set block parameter Maximum number of iterations to a positive integer value.
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.

RationaleSupport bounded iterative in the generated code.
Model Advisor ChecksCheck usage of While Iterator blocks (Simulink Check)
References

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

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

  • MISRA C:2012, Rule 14.2
    MISRA C:2012, Rule 16.4
    MISRA C:2012, Dir 4.1

  • INT32-C. Ensure that operations on signed integers do not result in overflow

Last ChangedR2021b

hisl_0007: Usage of For Iterator or While Iterator subsystems

ID: Titlehisl_0007: Usage of For Iterator or While Iterator subsystems
DescriptionTo support unambiguous behavior, when using For Iterator Subsystem or While Iterator Subsystem, avoid using sample time-dependent blocks, such as integrators, filters, and transfer functions within the subsystems.
RationaleAvoid ambiguous behavior from the subsystem.
Model Advisor ChecksCheck usage of For and While Iterator subsystems (Simulink Check)
References

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

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

  • MISRA C:2012, Rule 14.2
    MISRA C:2012, Rule 16.4
    MISRA C:2012, Dir 4.1

Last ChangedR2018b
Examples

The following example causes a warning: the Discrete FIR Filter block is time-dependent and is in a For or While Iterator subsystem.

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

Set block parameter Iteration limit source to internal.

B

When Iteration limit source must be external, use a block that has a constant value. Options include Width, Probe, or Constant.

C

Clear block parameters Set next i (iteration variable) externally.

D

To observe the iteration value during simulation, select block parameter Show iteration variable.

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 ChecksCheck usage of For Iterator blocks (Simulink Check)
References

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

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

  • MISRA C:2012, Rule 14.2
    MISRA C:2012, Rule 16.4
    MISRA C:2012, Dir 4.1

Last ChangedR2016a

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

Select block parameter 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.
Model Advisor ChecksCheck usage of If blocks and If Action Subsystem blocks (Simulink Check)
References

  • DO-331, Section MB.6.3.2.d – ‘Low-level requirements are verifiable’
    DO-331 Section MB.6.3.2.b – Low-level requirements are accurate and consistent

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • 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:2012, Rule 14.2
    MISRA C:2012, Rule 16.4
    MISRA C:2012, Dir 4.1

Last ChangedR2016b
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

Select block parameter 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.
Model Advisor ChecksCheck usage of Switch Case blocks and Switch Case Action Subsystem blocks (Simulink Check)
References

  • DO-331, Section MB.6.3.2.d – ‘Low-level requirements are verifiable
    DO-331 Section MB.6.3.2.b – Low-level requirements are accurate and consistent

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • 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:2012, Rule 14.2
    MISRA C:2012, Rule 16.4
    MISRA C:2012, Dir 4.1

Last ChangedR2016b
Examples

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

hisl_0024: Inport interface definition

ID: Titlehisl_0024: Inport interface definition
Description

To support strong data typing and unambiguous behavior of the model and the generated code, set parameters Data type, Port dimensions, and Sample time for each:

  • Model root-level inport

  • Signal object that explicitly resolves to a connected signal line

  • Architecture model root-level inport port

For export-function models, you can set Sample time to -1.

Note

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

Adhering to this guideline captures reusable specifications (e.g. array of structures) as a Simulink.ValueType object and specifies the data type of the In Bus Element and Out Bus Element blocks.

Rationale

  • Avoid ambiguous behavior.

  • Support full specification of the software interface.

Model Advisor ChecksCheck for root Inports with missing properties (Simulink Check)
References

  • DO-331 Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • IEC 61508-3, Table B.9 (6) ‘Fully defined interface’

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1a) – Enforcement of low complexity
    ISO 26262-6, Table 1 (1c) – Enforcement of strong typing
    ISO 26262-6, Table 1 (1f) – Use of unambiguous graphical representation
    ISO 26262-6, Table 3 (1c) – Restricted size of interfaces
    ISO 26262-6, Table 7 (1k) – Interface test

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

Last ChangedR2023b

hisl_0025: Design min/max specification of input interfaces

ID: Titlehisl_0025: Design min/max specification of input interfaces
Description

Provide design minimum and maximum interface ranges for each

  • root-level Inport block in Simulink® model

  • root-level Input port of Architecture model

Notes

  • Specifying the range of root level Input ports enables additional capabilities.aExamples 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 are used by Embedded Coder to optimize the generated code. To use these design ranges for optimization, select configuration parameter Optimize using the specified minimum and maximum values. This configuration parameter is applicable only when the System target file is an ERT-based target.

  • 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 ChecksCheck for root Inports with missing range definitions (Simulink Check)
References

  • DO-331, Section MB.6.3.2.d – ‘Low-level requirements are verifiable’
    DO-331 Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • IEC 61508-3, Table B.9 (6) ‘Fully defined interface’

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1c) – Enforcement of strong typing
    ISO 26262-6, Table 7 (1e) – Formal verification
    ISO 26262-6, Table 7 (1k) – Interface test
    ISO 26262-6, Table 8 (1c) – Analysis of boundary values
    ISO 26262-6, Table 3 (1c) – Restricted size of interfaces

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

Last ChangedR2022b

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
Description

Provide minimum and maximum interface ranges for each

  • root-level Outport block in Simulink model

  • root-level Outport ports of Architecture model

Notes

  • Specifying the range of root level Output ports enables additional capabilities.aExamples 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 are used by Embedded Coder to optimize the generated code. To set these design ranges, select configuration parameter Optimize using the specified minimum and maximum values. This configuration parameters is applicable only when the System target file is an ERT-based target.

  • 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 ChecksCheck for root Outports with missing range definitions (Simulink Check)
References

  • DO-331, Section MB.6.3.2.d – ‘Low-level requirements are verifiable’
    DO-331 Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • IEC 61508-3, Table B.9 (6) ‘Fully defined interface’

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1c) – Enforcement of strong typing
    ISO 26262-6, Table 7 (1e) – Formal verification
    ISO 26262-6, Table 7 (1k) – Interface test
    ISO 26262-6, Table 8 (1c) – Analysis of boundary values
    ISO 26262-6, Table 3 (1c) – Restricted size of interfaces

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

Last ChangedR2022b

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_0077: Outport interface definition

ID: Titlehisl_0077: Outport interface definition
Description

To support strong data typing and unambiguous behavior of the model and the generated code, set the parameters Data type, Port dimensions, and Sample time for each:

  • Model root-level outport

  • Signal object that explicitly resolves to a connected signal line

  • Architecture model root-level outport port

For export-function models, you can set Sample time to -1.

NoteUsing root-level Outport blocks without fully defined dimensions, sample times, or data type can lead to ambiguous simulation results.
Rationale

  • Avoid ambiguous behavior.

  • Support full specification of software interface.

Model Advisor ChecksCheck for root Outports with missing properties (Simulink Check)
References

  • DO-331 Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • IEC 61508-3, Table B.9 (6) ‘Fully defined interface’

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1a) – Enforcement of low complexity
    ISO 26262-6, Table 1 (1c) – Enforcement of strong typing
    ISO 26262-6, Table 1 (1f) – Use of unambiguous graphical representation
    ISO 26262-6, Table 3 (1c) – Restricted size of interfaces
    ISO 26262-6, Table 7 (1k) – Interface test

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

Last ChangedR2023a