|
|
|
| R2012a Documentation → Simulink Verification and Validation | |
Learn more about Simulink Verification and Validation |
|
|
|
|
| R2012a Documentation → Simulink Verification and Validation | |
Learn more about Simulink Verification and Validation |
|
| Contents | Index |
IEC 61508 and ISO 26262 checks facilitate designing and troubleshooting models, subsystems, and the corresponding generated code for applications to comply with IEC 61508-3 or ISO 26262–6.
The Model Advisor performs a checkout of the Simulink Verification and Validation license when you run the IEC 61508 or ISO 26262 checks.
If your model uses model referencing, run the IEC 61508 or ISO 26262 checks on all referenced models before running them on the top-level model.
IEC 61508–3 Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 3: Software requirements
ISO 26262–6 Road vehicles — Functional safety — Part 6: Product development: Software level
Developing Models and Code That Comply with the IEC 16508 Standard in the Embedded Coder documentation
Develop Models and Code That Comply with the ISO 26262 Standard in the Embedded Coder documentation
Consulting the Model Advisor in the Simulink documentation
Simulink Checks in the Simulink reference documentation
Embedded Coder Checks in the Simulink Coder documentation
Display number of elements and name, level, and depth of subsystems for the model or subsystem.
The IEC 61508 and ISO 26262 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.
The maximum subsystem depth of the given model.
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).
See
IEC 61508-3, Table A.9 (5) – Software complexity metrics
ISO/DIS 26262-6, Table 1 (1a) - Enforcement of low complexity, Table 4 (1a) - Hierarchical structure of software components, Table 4 (1b) - Restricted size of software components, and Table 4 (1c) - Restricted size of interfaces
| Condition | Recommended Action |
|---|---|
| N/A | This summary is provided for your information. No action is required. |
sldiagnostics in the Simulink documentation
Cyclomatic Complexity in the Stateflow documentation
Identify unconnected lines, input ports, and output ports in the model.
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.
See
IEC 61508-3, Table A.3 (3) — Language subset
ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1d) - Use of defensive implementation techniques
| Condition | Recommended Action |
|---|---|
| There are unconnected lines, input ports, or output ports in the model or subsystem. |
|
Working with Signals in the Simulink documentation
Identify root model Inport blocks that do not have fully defined attributes.
Using root model Inport blocks that do not have fully define dimensions, sample time, or data type can lead to undesired simulation results. Simulink back-propagates dimensions, sample times, and data types from downstream blocks unless you explicitly assign these values.
See
IEC 61508-3, Table B.9 (5) – Fully defined interface
ISO/DIS 26262-6, Table 1 (1f) - Use of unambiguous graphical representation
| Condition | Recommended Action |
|---|---|
| The model has root-level Inport blocks that have undefined attributes, such as an inherited sample time, data type, or port dimension. | Explicitly define root-level Inport block attributes identified in the results. Double-click an element from the list of underspecified items to locate the condition. |
The following configurations pass this check:
Inport blocks with inherited port dimensions in conjunction with the usage of bus objects
Inport blocks with automatically inherited data types in conjunction with bus objects
Inport blocks with inherited sample times in conjunction with the Periodic sample time constraint menu set to Ensure sample time independent
Working with Data Types in the Simulink documentation
Determining Output Signal Dimensions in the Simulink documentation
Specifying Sample Time in the Simulink documentation
Identify blocks not supported by code generation or not recommended for deployment.
This check partially identifies model constructs that are not suited for code generation or not recommended for 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.
See
IEC 61508-3, Table A.3 (3) – Language subset
ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets
| Condition | Recommended Action |
|---|---|
| The model or subsystem contains blocks that should not be used for code generation. | Consider replacing the blocks listed in the results. Double-click an element from the list of questionable items to locate condition. |
| The model or subsystem contains blocks that should not be used for production code deployment. | Consider replacing the blocks listed in the results. Double-click an element from the list of questionable items to locate condition. |
| The model or subsystem contains Gain blocks whose value equals 1. | If you are using Gain blocks as buffers, consider replacing them with Signal Conversion blocks. Double-click an element from the list of questionable items to locate condition. |
This check might not identify all instances of noncompliance with the Simulink Coder and Embedded Coder Simulink Built-In Blocks That Support Code Generation tables.
Simulink Built-In Blocks That Support Code Generation tables in the Simulink Coder documentation for Simulink Coder and Embedded Coder
Model Architecture and Design in the Embedded Coder documentation
Identify usage of Stateflow constructs that might impact safety.
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
| Condition | Recommended Action |
|---|---|
| A Stateflow chart is not configured for strong data typing on boundaries between a Simulink model and the Stateflow chart. (See hisf_0009: Strong data typing (Simulink and Stateflow boundary) IEC 61508-3 Table A.3 (2) - Strongly typed programming language, ISO/DIS 26262-6, Table 1 (1c) - Enforcement of strong typing, and MISRA-C:2004, Rules 10.1, 10.2, 10.3, and 10.4) | 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 and ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets) |
|
| 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 and ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets) | Define local data at the chart level or below. |
A new line is missing from a state action after:
(See IEC 61508-3, Table A.3 (3)- Language subset and ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets) | 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, and ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1f) - Use of unambiguous graphical representation) | For the specified charts, in the Chart Properties dialog box, select User specified state/transition execution order. |
Any of the following debugging options are
cleared:
(See hisf_0011: Stateflow debugging settings, IEC 61508-3, Table A.7 (2) - Simulation/modeling, and ISO/DIS 26262-6 Table 1 (1d) - Use of defensive implementation techniques) | Select the debugging options. In the Configuration Parameters dialog box, select:
In the Stateflow Debugging dialog box, select:
|
| 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, ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1e) - Use of established design principles, Table 1 (1h) - Use of naming conventions and MISRA-C:2004, Rule 5.6) | For the identified chart, do one of the following:
|
See the following topics in the Stateflow documentation:
See Stateflow Chart Considerations in the Simulink documentation.
Identify whether Stateflow charts are all Mealy or all Moore charts.
Compares the state machine type of all Stateflow charts to the type that you specify in the input parameters.
See
IEC 61508-3,Table A.7 (2) - Simulation/modeling
ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets
Check whether charts use the same state machine type, and are all Mealy or all Moore charts.
Check whether all charts are Mealy charts.
Check whether all charts are Moore charts.
| Condition | Recommended Action |
|---|---|
The input parameter is set to Common and
charts in the model use either of the following:
| 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. |
hisf_0001: Mealy and Moore semantics
Building Mealy and Moore Charts in the Stateflow documentation.
Stateflow Chart Considerations in the Simulink documentation.
Check whether Simulink blocks and Stateflow objects link to a requirements document.
See
IEC 61508-3, Table A.1 (1) - Computer-aided specification tools, Table A.2 (8) - Computer-aided specification tools, and Table A.8 (1) - Impact analysis
ISO/DIS 26262-6, Table 8 (1a) - Documentation of the software unit design in natural language
This check verifies whether Simulink blocks and Stateflow objects link to a document containing engineering requirements for traceability.
| Condition | Recommended Action |
|---|---|
| Blocks do not link to a requirements document. | Link to requirements document. See Links Between Models and Requirements. |
When you run this check, the Model Advisor does not follow library links or look under masks.
Run this check from the top model or subsystem that you want to check.
Identify blocks with inconsistent indexing method.
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.
See
IEC 61508–3, Table A.3 (3) 'Language subset'
IEC 61508–3, Table A.4 (5) 'Design and coding standards'
ISO/DIS 26262-6, Table 1 (b) 'Use of language subsets'
ISO/DIS 26262-6, Table 1 (f) 'Use of unambiguous graphical
representation'
| Condition | Recommended 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. |
Identify usage of Math Operation blocks that might impact safety.
This check inspects the usage of:
Absolute Value blocks
Gain blocks
See
IEC 61508-3, Table A.3 (3) – Language subset, IEC 61508-3, Table A.4 (3) – Defensive programming, Table B.8 (3) – Control Flow Analysis
ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1d) - Use of defensive implementation techniques, Table 7 (1f) - Control flow analysis
MISRA-C:2004, Rule 21.1
| Condition | Recommended Action |
|---|---|
| The model or subsystem contains an Absolute Value block that is operating on a Boolean or an unsigned input data type. This condition results in unreachable simulation pathways through the model and might result in unreachable code. | For the identified block, do one of the following:
|
| The model or subsystem contains an Absolute Value block that is operating on a signed integer value, and the Saturate on integer overflow check box is 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. | In the Block Parameters > Signal Attributes dialog box, select the Saturate on integer overflow check box. |
| The model or subsystem contains Gain blocks with a of value 1. | If you are using Gain blocks as buffers, consider replacing them with Signal Conversion blocks. |
Identify usage of Signal Routing blocks that might impact safety.
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.
See
IEC 61508-3, Table A.3 (3) – Language subset, Table A.4 (3) – Defensive programming
ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1d) - Use of defensive implementation techniques
MISRA-C:2004, Rule 13.3
| Condition | Recommended 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:
|
Identify usage of Logical Operator and Bit Operations blocks that might impact safety.
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
See
IEC 61508-3, Table A.3 (2) – Strongly typed programming language, Table A.3 (3) – Language subset, Table A.4 (3) - Defensive programming
ISO/DIS 26262-6, Table 1 (1c) - Enforcement of strong typing, Table 1 (1b) - Use of language subsets
MISRA-C:2004, Rule 13.3
| Condition | Recommended 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:
|
| 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. |
|
hisl_0016: Usage of blocks that compute relational operators
hisl_0017: Usage of blocks that compute relational operators (2)
Identify usage of Ports and Subsystems blocks that might impact safety.
This check inspects the usage of:
For Iterator blocks
While Iterator blocks
If blocks
Switch Case blocks
See
IEC 61508-3, Table A.3 (3) - Language subset, Table A.4 (3) - Defensive programming
ISO/DIS 26262-6, Table 1 (1b) - Use of language subsets, Table 1 (1d) - Use of defensive implementation techniques
MISRA-C:2004, Rule 13.6, Rule 14.10, Rule 15.3, Rule 21.1
| Condition | Recommended 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:
|
| 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:
|
| 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. |
hisl_0010: Usage of If blocks and If Action Subsystem blocks
hisl_0011: Usage of Switch Case blocks and Action Subsystem blocks
Display model configuration and checksum information.
This informer check displays the following information for the current model:
Model version number
Model author
Date
Model checksum
See
IEC 61508-3, Table A.8 (5) – Software configuration management
ISO/DIS 26262-8, Clause 7.4.2
| Condition | Recommended Action |
|---|---|
| Could not retrieve model version and checksum information. | This summary is provided for your information. No action is required. |
How Simulink Helps You Manage Model Versions in the Simulink documentation
Model Change Log in the Simulink Report Generator™ documentation
Simulink.BlockDiagram.getChecksum in the Simulink documentation
Simulink.SubSystem.getChecksum in the Simulink documentation
 | DO-178B Checks | MathWorks Automotive Advisory Board Checks |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
