Main Content

Ports & Subsystems

hisl_0006: Usage of While Iterator blocks

ID: Title hisl_0006: Usage of While Iterator blocks
Description To support bounded iterative behavior in the generated code when using theWhile Iteratorblock, set block parameterMaximum number of iterationsto a positive integer value.
Note

When you useWhile Iteratorsubsystems, 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 theWhile Iteratorblock parameterShow iteration number port. If the loop reaches the maximum number of iterations, verify the output values of theWhile Iteratorblock.
Rationale Support bounded iterative in the generated code.
Model Advisor Checks Check 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 Changed R2021b

hisl_0007: Usage of For Iterator or While Iterator subsystems

ID: Title hisl_0007: Usage of For Iterator or While Iterator subsystems
Description To support unambiguous behavior, when usingFor Iterator SubsystemorWhile Iterator Subsystem, avoid using sample time-dependent blocks, such as integrators, filters, and transfer functions within the subsystems.
Rationale Avoid ambiguous behavior from the subsystem.
Model Advisor Checks Check 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 Changed R2018b
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: Title hisl_0008: Usage of For Iterator blocks
Description

To support bounded iterative behavior in the generated code when using theFor Iteratorblock, do one of the following:
A

Set block parameterIteration limit sourcetointernal.
B

WhenIteration limit sourcemust beexternal, use a block that has a constant value. Options includeWidth,Probe, orConstant.
C

Clear block parametersSet next i (iteration variable) externally.
D

To observe the iteration value during simulation, select block parameterShow iteration variable.
Notes

When you use theFor Iteratorblock, 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.
Rationale A, B, C, D Support bounded iterative behavior in generated code.
Model Advisor Checks Check 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 Changed R2016a

hisl_0010: Usage of If blocks and If Action Subsystem blocks

ID: Title hisl_0010: Usage of If blocks and If Action Subsystem blocks
Description

To support verifiable generated code, when using theIfblock with nonemptyElseifexpressions,
A

Select block parameterShow else condition.
B

Connect the outports of theIfblock toIf Action Subsystemblocks.
Prerequisites

hisl_0016: Usage of blocks that compute relational operators
Notes

The combination ofIfandIf Action Subsystemblocks enable conditional execution based on input conditions. When there is only anifbranch, you do not need to include anelsebranch.
Rationale A, B Support generation of verifiable code.
Model Advisor Checks Check 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 Changed R2016b
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: Title hisl_0011: Usage of Switch Case blocks and Action Subsystem blocks
Description

To support verifiable generated code, when using theSwitch Caseblock:
A

Select block parameterShow default case.
B

Connect the outports of theSwitch Caseblock to aSwitch Case Action Subsystemblock.
C

Use an integer data type or an enumeration value for the inputs toSwitch Caseblocks.
Prerequisites

hisl_0016: Usage of blocks that compute relational operators
Notes

The combination ofSwitch CaseandIf Action Subsystemblocks enable conditional execution based on input conditions. Provide a default path of execution in the form of a “Default” block.
Rationale A, B, C Support generation of verifiable code.
Model Advisor Checks Check 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 Changed R2016b
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: Title hisl_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, exceptConstant.Constant块可以使用无限(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.
Rationale A, B Support unambiguous behavior.
Model Advisor Checks Check usage of conditionally executed subsystems(Simulink Check)
References

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

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

    DO-331, Section MB 6.3.2.b 'Low-level requirements are accurate and consistent'
Last Changed R2018b
Examples When 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: Title hisl_0024: Inport interface definition
Description

To support strong data typing and unambiguous behavior of the model and the generated code, set parametersData type,Port dimensions, andSample timefor 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 setSample timeto-1.
Note Using root-levelInportblocks without fully defined dimensions, sample times, or data type can lead to ambiguous simulation results.
Rationale

  • Avoid ambiguous behavior.

  • Support full specification of the software interface.
Model Advisor Checks Check 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、表B.9 interfac(6)“完全定义e’

  • 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 Changed R2023a

hisl_0025: Design min/max specification of input interfaces

ID: Title hisl_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-levelInputport of Architecture model
Notes

  • Specifying the range of root levelInputports enables additional capabilities.aExamples include:

    • Detection of overflows through simulation range checking.

    • Code optimizations using Embedded Coder®.

    • Design model verification usingSimulink Design Verifier™.

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

  • 使用指定的设计范围嵌入式编码器to optimize the generated code. To use these design ranges for optimization, select configuration parameterOptimize using the specified minimum and maximum values. This configuration parameter is applicable only when theSystem target fileis 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 Checks Check 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、表B.9 interfac(6)“完全定义e’

  • 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 Changed R2022b

aThese 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: Title hisl_0026: Design min/max specification of output interfaces
Description

Provide minimum and maximum interface ranges for each

  • root-levelOutportblock in Simulink model

  • root-levelOutportports of Architecture model
Notes

  • Specifying the range of root levelOutputports enables additional capabilities.aExamples include:

    • Detection of overflows through simulation range checking.

    • Code optimizations using Embedded Coder.

    • Design model verification usingSimulink Design Verifier.

    • Fixed-point autoscaling using Fixed-Point Designer.

  • 使用指定的设计范围嵌入式编码器to optimize the generated code. To set these design ranges, select configuration parameterOptimize using the specified minimum and maximum values. This configuration parameters is applicable only when theSystem target fileis an ERT-based target.

  • Ranges for bus-typeOutportblocks 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 Check 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、表B.9 interfac(6)“完全定义e’

  • 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 Changed R2022b

aThese 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: Title hisl_0077: Outport interface definition
Description

To support strong data typing and unambiguous behavior of the model and the generated code, set the parametersData type,Port dimensions, andSample timefor 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 setSample timeto-1.
Note Using root-levelOutportblocks 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 ambiguous behavior.

  • Support full specification of software interface.
Model Advisor Checks Check 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、表B.9 interfac(6)“完全定义e’

  • 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 Changed R2023a