Signal Routing

hisl_0013: Usage of data store blocks

ID: Titlehisl_0013: Usage of data store blocks
DescriptionTo support deterministic behavior across different sample times or models when using data store blocks, including Data Store Memory, Data Store Read, and Data Store Write:

In the Configuration Parameters dialog, on the Diagnostics > Data Validity pane, set these Data Store Memory parameters to error:

  • Detect read before write

  • Detect write after read

  • Detect write after write

  • Multitask data store

  • Duplicate data store names

Notes

Using data store memory blocks can have significant impact on your software verification effort. Models and subsystems that use only inports and outports to pass data provide a directly traceable interface, simplifying the verification process.

To provide deterministic data transfer between different rates and tasks, use Rate Transition blocks before Data Store Write blocks or after Data Store Read blocks.

In addition to the diagnostics, you can more accurately detect data store memory access violations in your model using Simulink® Design Verifier™. To do this, on the Design Verifier tab, select Settings. In the Configuration Parameters dialog box, on the Design Verifier > Design Error Detection pane, select Data store access violations. For more information, see Detect Data Store Access Violations in a Model (Simulink Design Verifier). A Simulink Design Verifier license is required.

Rationale

Support consistent data values across different sample times or models.

Prevent unintended data corruption.

Model Advisor ChecksCheck safety-related diagnostic settings for data store memory (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 (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'

  • DO-331, Section MB.6.3.3.b 'Software architecture is consistent’

Last ChangedR2020b
Examples

The following examples use Rate Transition blocks to provide deterministic data transfer between different rates and tasks.

For fast-to-slow transitions:

Set the rate of the slow sample time on either the Rate Transition block or the Data Store Write block.

Do not place the Rate Transition block after the Data Store Read block.

For slow-to-fast transitions:

If the Rate Transition block is after the Data Store Read block, specify the slow rate on the Data Store Read block.

If the Rate Transition block is before the Data Store Write block, use the inherited sample time for the blocks.

hisl_0015: Usage of Merge blocks

ID: Titlehisl_0015: Usage of Merge blocks
Description

To support unambiguous behavior from Merge blocks,

A

Use Merge blocks only with conditionally executed subsystems.

B

Specify execution of the conditionally executed subsystems such that only one subsystem executes during a time step.

C

Clear block parameter Allow unequal port widths.

DSet the Outport block parameter Output when disabled to held for each conditionally executed subsystem being merged.
Notes

Simulink combines the inputs of the Merge block into a single output. The output value at any time is equal to the most recently computed output of the blocks that drive the Merge block. Therefore, the Merge block output is dependent upon the execution order of the input computations.

To provide predictable behavior of the Merge block output, you must have mutual exclusion between the conditionally executed subsystems feeding a Merge block.

Merge block parameter Allow unequal port widths is only available when configuration parameter Underspecified initialization detection is set to Classic.

Prerequisites

hisl_0303: Configuration Parameters > Diagnostics > Merge block

hisl_0304: Configuration Parameters > Diagnostics > Model initialization

RationaleA, B, C, DAvoid unambiguous behavior.
Model Advisor ChecksCheck usage of Merge blocks (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, Section MB.6.3.3.b 'Software architecture is consistent’

See Also

Merge block in the Simulink documentation

Last ChangedR2018b
Examples

Recommended

Not Recommended

hisl_0021: Consistent vector indexing method

ID: Titlehisl_0021: Consistent vector indexing method
DescriptionWithin a model, use:
A

Consistent vector indexing method.

Supports configurable indexing:

Support only one-based indexing:

Supports only zero-based indexing:

  • Stateflow chart with C action language

  • Truth Table function with C action language

RationaleAReduce the risk of introducing errors due to inconsistent indexing.
Model Advisor ChecksCheck for inconsistent vector indexing methods (Simulink Check)
References
  • IEC 61508–3, Table A.3 (3) 'Language subset'
    IEC 61508–3, Table A.4 (5) 'Design and coding standards'

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1b) 'Use of language subsets'
    ISO 26262-6, Table 1 (1e) 'Use of well-trusted design principles'
    ISO 26262-6, Table 1 (1f) 'Use of unambiguous graphical representation'
    ISO 26262-6, Table 1 (1g) 'Use of style guide'
    ISO 26262-6, Table 1 (1h) 'Use of naming conventions'

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

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

See Alsocgsl_0101: Zero-based indexing
Last ChangedR2019a

hisl_0022: Data type selection for index signals

ID: Titlehisl_0022: Data type selection for index signals
DescriptionFor index signals, use:
AAn integer or enumerated data type
BA data type that covers the range of indexed values.

Blocks that use a signal index include:

  • Assignment

  • Direct Lookup Table (n-D)

  • Index Vector

  • Interpolation Using Prelookup

  • MATLAB® Function

  • Multiport Switch

  • Selector

  • Stateflow® Chart

RationaleAPrevent unexpected results that can occur with rounding operations for floating-point data types.
BEnable access to data in a vector.
Model Advisor ChecksCheck data types for blocks with index signals (Simulink Check)
References
  • IEC 61508–3, Table A.3 (2) 'Strongly typed programming language'
    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 (1c) 'Enforcement of strong typing'
    ISO 26262-6, Table 1 (1d) 'Use of defensive implementation techniques'

  • EN 50128, Table A.4 (8) 'Strongly Typed Programming Language'
    EN 50128, Table A.3 (1) 'Defensive Programming'

  • DO-331, Section MB.6.3.4.f 'Accuracy and Consistency of Source Code'

Last ChangedR2018b

hisl_0023: Verification of variant blocks

ID: Titlehisl_0023: Verification of variant blocks
DescriptionWhen verifying that a model is consistent with generated code, do the following:
AFor each Variant Model block, clear block parameter Generate preprocessor conditionals.
BFor each Variant Subsystem block, set the Variant activation time to update diagram.
CVerify combinations of model variants that might be active in the generated code.
RationaleA,BSimplify consistency testing between the model and generated code by restricting the code base to a single variant.
CVerify that consistency testing between the model and generated code is complete for variants.
Model Advisor ChecksCheck usage of variant blocks (Simulink Check)
References
  • DO-331, Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • IEC 61508–3, Table A.4 (7) 'Use of trusted / verified software modules and components'

Last ChangedR2017b

hisl_0034: Usage of Signal Routing blocks

ID: Titlehisl_0034: Usage of Signal Routing blocks
Description

When using Switch blocks, avoid comparisons using the ~= operator on floating-point data types.

Note

Due to floating-point precision issues, do not test floating-point expressions for inequality (~=).

When the model contains a Switch block computing a relational operator with the ~= operator, the inputs to the block must not be single, double, or any custom storage class that is a floating-point type. Change the data type of the input signals, or rework the model to eliminate using the ~= operator within Switch blocks.

Rationale

Improve model robustness.

Model Advisor ChecksCheck usage of Signal Routing blocks (Simulink Check)
References
  • DO-331, Sections MB.6.3.1.g and MB.6.3.2.g 'Algorithms are accurate'

  • IEC 61508-3, Table A.3 (3) – 'Language subset'
    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'
    Table 1 (1d) - 'Use of defensive implementation techniques'

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

  • MISRA C:2012, Dir 1.1

Last ChangedR2017b