| Simulink® Verification and Validation™ | |
| On this page… |
|---|
Display model metrics and complexity Check for fully defined interface |
IEC 61508 checks facilitate designing and troubleshooting Simulink models and subsystems and the code that you generate from it for applications that need to comply with IEC 61508-3.
If your model uses model referencing, run the IEC 61508 checks on all referenced models before running them on the top-level model.
Developing Models and Code That Comply with the IEC 16508 Standard in the Real-Time Workshop Embedded Coder documentation
Consulting the Model Advisor in the Simulink documentation
Simulink Checks in the Simulink reference documentation
Real-Time Workshop Checks in the Real-Time Workshop documentation
IEC functional safety zone Web site (http://www.iec.ch/zone/fsafety)
Display model metrics and complexity information.
The IEC 61508 standard recommends the usage of size and complexity metrics to assess the software under development. This check provides model 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.
| 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.
| 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.
| 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 all 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 Real-Time Workshop and Real-Time Workshop 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.
| 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 Real-Time Workshop and Real-Time Workshop Embedded Coder Simulink Block Support tables.
Simulink Block Support tables in the Real-Time Workshop documentation for Real-Time Workshop and Real-Time Workshop Embedded Coder
Requirements and Restrictions for ERT-Based Simulink Models in the Real-Time Workshop Embedded Coder documentation
Identify usage of Stateflow that can 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
See
IEC 61508-3, Table A.3 (2) – Strongly typed programming language
IEC 61508-3, Table A.3 (3) – Language subset
IEC 61508-3, Table B.9 (2) – Information hiding/encapsulation
MISRA C:2004, Rule 10.1
MISRA C:2004, Rule 10.2
MISRA C:2004, Rule 10.3
MISRA C:2004, Rule 10.4
MAAB Control Algorithm Modeling Guidelines, db_0122: Stateflow and Simulink interface signals and parameters
MAAB Control Algorithm Modeling Guidelines, db_0123: Stateflow port names
MAAB Control Algorithm Modeling Guidelines, db_0125: Scope of internal signals and local auxiliary variables
MAAB Control Algorithm Modeling Guidelines, db_0126: Scope of Events
MAAB Control Algorithm Modeling Guidelines, jc_0501: Format of entries in a state block
| Condition | Recommended Action |
|---|---|
| A Stateflow chart is not configured for strong data typing on boundaries between a Simulink model and theStateflow chart. | Enable the option Use Strong Data Typing with Simulink I/O for the Stateflow chart. When you enable this option, 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. |
|
| Events are not defined in the Stateflow hierarchy at the chart level or below. | Define events at the chart level or below. |
| Local data is not defined in the Stateflow hierarchy at the chart level or below. | Define local data at the chart level or below. |
A new line is missing from a state action after
| Add missing new lines. |
See the following topics in the Stateflow documentation
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.
| 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
Identify usage of Simulink blocks that can impact safety.
Blocks that you use incorrectly can result in unreachable code, incorrect or unpredictable results, infinite loops, and unpredictable execution times in generated code.
This check inspects your model for proper usage of:
Abs blocks
Blocks that compute relational operators including Relational Operator, Compare To Constant, Compare To Zero, and Detect Change blocks
While Iterator blocks
For Iterator blocks
See
IEC 61508-3, Table A.3 (2) – Strongly typed programming language
IEC 61508-3, Table A.3 (3) – Language subset
IEC 61508-3, Table A.4 (3) – Defensive programming
IEC 61508-3, Table B.8 (3) – Control Flow Analysis
MISRA C:2004, Rule 13.3
MISRA C:2004, Rule 13.6
MISRA C:2004, Rule 14.1
MISRA C:2004, Rule 21.1
| Condition | Recommended Action |
|---|---|
| The model or subsystem contains an Abs 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. |
|
| The model or subsystem contains an Abs block that is operating on a signed integer value, and the Saturate on integer overflow check box is cleared. For signed data types, the absolute value of the most negative value is problematic since it is not representable by the data type. This condition results in an overflow in the generated code. | Select the Saturate on integer overflow check box of the specified Abs blocks. |
| 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. | For the specified blocks, use common data types as inputs. |
| The model or subsystem contains a block computing a relational operator that is not generating Boolean data as its output. This condition violates strong data typing rules and can lead to unpredictable results in the generated code. | Set the Output data type to boolean in the Block Parameters > Signal Attributes pane 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, and can lead to unpredictable results in the generated code. | For the specified 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 specified While Iterator blocks:
|
| 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 specified For Iterator blocks, do one of the following:
|
Descriptions of the following blocks in the Simulink reference documentation:
Abs block
Relational Operator block
Compare To Constant block
Compare To Zero block
Detect Change block
While Iterator block
For Iterator block
| DO-178B Checks | MathWorks Automotive Advisory Board Checks | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |