Documentation

IEC 61508, IEC 62304, ISO 26262, and EN 50128 Checks

IEC 61508, IEC 62304, ISO 26262, and EN 50128 Checks

IEC 61508, IEC 62304, 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, IEC 62304, 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, IEC 62304, ISO 26262, or EN 50128 checks.

Tips

If your model uses model referencing, run the IEC 61508, IEC 62304, 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

  • IEC 62304 Medical device software - Software life cycle processes

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

Check model object names

Check ID: mathworks.iec61508.hisl_0032

Check model object names.

Description

This check verifies that the following model object names comply with your own modeling guidelines or the high-integrity modeling guidelines. The check also verifies that the model object does not use a reserved name.

  • Blocks

  • Signals

  • Parameters

  • Busses

  • Stateflow® objects

Reserved names:

  • MATLAB® keywords

  • Reserved keywords for C, C++, and code generation. For complete list, see Reserved Keywords in the Simulink Coder™ documentation.

  • int8 , uint8

  • int16, uint16

  • int32, uint32

  • inf, Inf

  • NaN, nan

  • eps

  • intmin, intmax

  • realmin, realmax

  • pi

  • infinity

  • Nil

    Note:   For some cases, the Model Advisor reports an issue in multiple subchecks of this check.

Available with Simulink Verification and Validation.

Input Parameters

To specify the naming standard and model object names that the check flags, use the Model Advisor Configuration Editor.

  1. Open the Model Configuration Editor and navigate to Check model object names. In the Input Parameters pane, for each of the model objects, select one of the following:

    • MAAB to use the MAAB naming standard. When you select MAAB, the check uses the regular expression (^.{32,}$)|([^a-zA-Z_0-9])|(^\d)|(^ )|(__)|(^_)|(_$) to verify that names:

      • Use these characters: a-z, A-Z, 0-9, and the underscore (_).

      • Do not start with a number.

      • Do not use underscores at the beginning or end of a string.

      • Do not use more than one consecutive underscore.

      • Use strings that are less than 32 characters.

    • Custom to use your own naming standard. When you select Custom, you can enter your own Regular expression for prohibited <model object> names. For example, if you want to allow more than one consecutive underscore, enter (^.{32,}$)|([^a-zA-Z_0-9])|(^\d)|(^ )|(^_)|(_$)

    • None if you do not want the check to verify the model object name

  2. Click Apply.

  3. Save the configuration. When you run the check using this configuration, the check uses the input parameters that you specified.

Results and Recommended Actions

ConditionRecommended Action
The model object names do not comply with the naming standard specified in the input parameters.Update the model object names to comply with your own or the high-integrity guidelines.

Capabilities and Limitations

  • Does not run on library models.

  • Analyzes content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

Display model metrics and complexity report

Check ID: mathworks.iec61508.MdlMetricsInfo

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, including library linked blocks.

  • 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).

  • The maximum subsystem depth of the given model.

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

  • Runs on library models.

  • Analyzes content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Does not allow exclusions of blocks or charts.

See Also

  • IEC 61508-3, Table B.9 (1) - Software module size limit, Table B.9 (2) - Software complexity control

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1a) - Enforcement of low complexity, Table 3 (a) - Hierarchical structure of software components, Table 3 (b) - Restricted size of software components, and Table 3 (c) - 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 for Stateflow Charts in the Simulink Verification and Validation documentation

Check for unconnected objects

Check ID: mathworks.iec61508.UnconnectedObjects

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

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

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

  • 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

  • Signal Basics

Check for root Inports with missing properties

Check ID: mathworks.iec61508.RootLevelInports

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. You can specify Inport block properties with block parameters or Simulink signal objects that explicitly resolve to the connected signal lines. When you run the check, a results table provides links to Inport blocks and signal objects 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 and Simulink signal objects, specify port dimensions.

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

For the listed Inport blocks and Simulink signal objects, specify data types.

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

For the listed Inport blocks and Simulink signal objects, 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.

Implicit resolution to a Simulink signal object — Model contains Inport block signal names that implicitly resolve to a Simulink signal object in the base workspace, model workspace, or Simulink data dictionary.

For the listed Simulink signal objects, in the property dialog, select signal property Signal name must resolve to Simulink signal object.

Capabilities and Limitations

  • Does not run on library models.

  • Allows exclusions of blocks and charts.

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

Check for MATLAB Function interfaces with inherited properties

Check ID: mathworks.iec61508.himl_0002

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

Description

The check identifies MATLAB Functions with inherited complexity or data type properties. A results table provides links to MATLAB Functions 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 Functions have inherited interfaces.

Explicitly define complexity and data type properties for inports, outports, and parameters of MATLAB Functions 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.

Capabilities and Limitations

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

Check MATLAB Function metrics

Check ID: mathworks.iec61508.himl_0003

Display complexity and code metrics for 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 Functions. The check additionally reports metric violations.

A results table provides links to 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 violates the complexity input parameters.For the 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.

Capabilities and Limitations

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

  • EN 50128, Table A.1(11) - Software Interface Specifications

  • himl_0003: Limitation of MATLAB function complexity

Check for root Inports with missing range definitions

Check ID: mathworks.iec61508.InportRange

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. You can specify Inport block minimum and maximum values with block parameters or Simulink signal objects that explicitly resolve to the connected signal lines. A results table provides links to Inport blocks and signal objects 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 — Model contains Inport blocks with numeric data types that have missing range parameters (minimum and/or maximum).

For the listed Inport blocks and Simulink signal objects, specify scalar minimum and maximum parameters.

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

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

Range specified will be ignored — Minimum or maximum values at Inports or Simulink signal objects 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 or Simulink signal objects with inherited data types.

Specify one of the supported data types:

Implicit resolution to a Simulink signal object — Model contains Inport block signal names that implicitly resolve to a Simulink signal object in the base workspace, model workspace, or Simulink data dictionary.

For the listed Simulink signal objects, in the property dialog, select signal property Signal name must resolve to Simulink signal object.

Capabilities and Limitations

  • Does not run on library models.

  • Allows exclusions of blocks and charts.

See Also

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

  • hisl_0025: Design min/max specification of input interfaces

Check for root Outports with missing range definitions

Check ID: mathworks.iec61508.OutportRange

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. You can specify Outport block minimum and maximum values with block parameters or Simulink signal objects that explicitly resolve to the connected signal lines. 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 — Model contains Outport blocks with numeric data types that have missing range parameters (minimum and/or maximum).

For the listed Outport blocks and Simulink signal objects, specify scalar minimum and maximum parameters.

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

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

Range specified at Outport will be ignored — Minimum or maximum values at Outports or Simulink signal objects 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 — Model contains Outport block or Simulink signal objects with inherited bus data types.

For the Outport blocks and Simulink signal objects, specify one of the supported data types:

Implicit resolution to a Simulink signal object — Model contains Outport block signal names that implicitly resolve to a Simulink signal object in the base workspace, model workspace, or Simulink data dictionary.

For the listed Simulink signal objects, in the property dialog, select signal property Signal name must resolve to Simulink signal object.

Capabilities and Limitations

  • Does not run on library models.

  • Allows exclusions of blocks and charts.

See Also

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

  • hisl_0026: Design min/max specification of output interfaces

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

Check ID: mathworks.iec61508.PCGSupport

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

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • 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

Check ID: mathworks.iec61508.StateflowProperUsage

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • 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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • 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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • 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:
  • hisf_0002: User-specified state/transition execution order

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

For the specified charts, in the Chart Properties dialog box, select User specified state/transition execution order.
Any of the following:
  • Wrap on overflow is not set to error.

  • Simulation range checking is not set to error.

  • Detect Cycles is cleared.

See:
  • hisf_0011: Stateflow debugging settings

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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

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

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

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

In the Configuration Parameters dialog box, set:

  • Diagnostics > Data Validity > Wrap on overflow to error.

  • Diagnostics > Data Validity > Simulation range checking to error.

In the model window, select:

  • Simulation > Debug > MATLAB & Stateflow Error Checking Options > 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

  • IEC 62304, 5.5.3 - Software Unit acceptance criteria

  • ISO 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1e) - Use of established design principles, Table 1 (1f) - Use of unambiguous graphical representation, Table 1 (1g) - Use of style guides, 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

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

  • Does not run on library models.

  • Analyzes content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts. Exclusions will not work for library linked charts.

See Also

See the following topics in the Stateflow documentation:

Check state machine type of Stateflow charts

Check ID: mathworks.iec61508.hisf_0001

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

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

Check for model objects that do not link to requirements

Check ID: mathworks.iec61508.RequirementInfo

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

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in masked subsystems that have no workspaces and no dialogs.

  • Allows exclusions of blocks and charts.

Tip

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

See Also

  • IEC 61508-3, Table A.2 (12) - Computer-aided specification and design tools, Table A.2 (9) - Forward traceability between the software safety requirements specification and software architecture, Table A.2 (10) - Backward traceability between the software safety requirements specification and software architecture, Table A.4 (8) - Forward traceability between the software safety requirements specification and software design, Table A.8 (1) - Impact analysis

  • IEC 62304, 5.2 - Software requirements analysis, 7.4.2 - Analyze impact of software changes on existing risk control measures

  • ISO 26262-6, Table 8 (1a) - Documentation of the software unit design in natural language, ISO 26262-6: 7.4.2.a - The verifiability of the software architectural design, ISO 26262-8: 8.4.3 Change request analysis

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

  • Requirements Traceability

Check for inconsistent vector indexing methods

Check ID: mathworks.iec61508.hisl_0021

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

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in masked subsystems that have no workspaces and no dialogs.

  • Allows exclusions of blocks and charts.

See Also

  • IEC 61508–3, Table A.3 (3) - Language subset, 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, Table 1 (1e) - Use of established design principles, Table 1 (1f) - Use of unambiguous graphical representation, Table 1 (1g) - Use of style guides, Table 1 (1h) - Use of naming conventions

  • 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 ID: mathworks.iec61508.himl_0004

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

Capabilities and Limitations

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Does not allow exclusions of blocks or charts.

See Also

  • IEC 61508-3, Table A.3 (3) - Language subset, Table A.4 (3) - Defensive programming, 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, Table 1 (1d) - Use of defensive implementation techniques, Table 1 (1e) - Use of established design principles, Table 1 (1f) - Use of unambiguous graphical representation, Table 1 (1g) - Use of style guides, Table 1 (1h) - Use of naming conventions

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

  • Check Code for Errors and Warnings

  • himl_0004: MATLAB Code Analyzer recommendations for code generation

Check MATLAB code for global variables

Check ID: mathworks.iec61508.himl_0005

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.

Capabilities and Limitations

  • Runs on library models.

  • Does not analyze content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Does not allow exclusions of blocks or charts.

See Also

Check usage of Math Operations blocks

Check ID: mathworks.iec61508.MathOperationsBlocksUsage

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 or an identity matrix.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 or Warning.

Set block parameter Action if any output element is not assigned to one of the recommended values:

  • Error, if Assignment block is not in an Iterator subsystem.

  • Warning, if Assignment block is in an Iterator subsystem.

Capabilities and Limitations

  • Does not run on library models.

  • Analyzes content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

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

  • 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, Table 9 (1f) - Control flow analysis

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

  • MISRA C:2012, Dir 4.1

  • MISRA C:2012, Rule 9.1

  • hisl_0001: Usage of Abs block

  • hisl_0029: Usage of Assignment blocks

Check usage of Signal Routing blocks

Check ID: mathworks.iec61508.SignalRoutingBlockUsage

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.

Capabilities and Limitations

  • Does not run on library models.

  • Analyzes content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

  • 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

Check usage of Logic and Bit Operations blocks

Check ID: mathworks.iec61508.LogicBlockUsage

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 All Parameters pane, consider selecting the Implement logic signals as boolean data (vs. double).

Capabilities and Limitations

  • Does not run on library models.

  • Analyzes content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

Check usage of Ports and Subsystems blocks

Check ID: mathworks.iec61508.PortsSubsystemsUsage

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.
The model or subsystem contains one of the following time-dependent blocks in a For Iterator or While Iterator subsystem:
  • Discrete Filter

  • Discrete FIR Filter

  • Discrete State-Space

  • Discrete Transfer Fcn

  • Discrete Zero-Pole

  • Transfer Fcn First Order

  • Transfer Fcn Lead or Lag

  • Transfer Fnc Real Zero

  • Discrete Derivative

  • Discrete Transfer Fcn (with initial outputs)

  • Discrete Transfer Fcn (with initial states)

  • Discrete Zero-Pole (with initial outputs)

  • Discrete Zero-Pole (with initial states)

In the model or subsystem, consider removing the time-dependent blocks.

Capabilities and Limitations

  • Does not run on library models.

  • Analyzes content of library linked blocks.

  • Analyzes content in all masked subsystems.

  • Allows exclusions of blocks and charts.

See Also

Display configuration management data

Check ID: mathworks.iec61508.MdlVersionInfo

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.

Capabilities and Limitations

  • Does not run on library models.

  • Does not allow exclusions of blocks or charts.

See Also

Was this topic helpful?