DO-178C/DO-331 checks facilitate designing and troubleshooting models from which code is generated for applications that must meet safety or mission-critical requirements.
The Model Advisor performs a checkout of the Simulink® Check™ license when you run the DO-178C/DO-331 checks.
These checks are qualified by the DO Qualification Kit for use in projects involving the DO-178 standard and related standards.
Simulink Checks (Simulink)
Simulink Coder Checks (Simulink Coder)
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178C Software Considerations in Airborne Systems and Equipment Certification and related standards
Check ID:
mathworks.do178.CodeSet
Check model configuration for code generation settings that can impact safety.
This check verifies that model configuration parameters for code generation are set optimally for a safety-related application.
Available with Simulink Check.
Condition | Recommended Action |
---|---|
The option to include comments in the generated code is cleared. Comments provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.) | Select Include
comments (Simulink Coder) on the Code Generation > Comments pane in the Configuration Parameters dialog box or set the parameter
GenerateComments to on . |
The option to include comments that describe the code for blocks is cleared. Comments provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.) | Select Simulink block comments (Simulink Coder)
on the Code Generation > Comments pane in the Configuration Parameters dialog box or set the parameter
SimulinkBlockComments to on . |
The option to include comments that describe the code for blocks eliminated from a model is cleared. Comments provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.) | Select Show
eliminated blocks (Simulink Coder) on the Code Generation > Comments pane in the Configuration Parameters dialog box or set the parameter
ShowEliminatedStatement to on . |
The option to include the names of parameter variables and source blocks as
comments in the model parameter structure declaration in
is cleared. Comments
provide good traceability between the code and the model. (See DO-331, Section
MB.6.3.4.e – Source code is traceable to low-level requirements.) | Select Verbose
comments for 'Model default' storage class (Simulink Coder) on the Code Generation > Comments pane in the Configuration Parameters dialog box or set the parameter
ForceParamTrailComments to on . |
The option to include requirement descriptions assigned to Simulink blocks as comments is cleared. Comments provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.) | Select Requirements in block comments (Embedded Coder) on the Code Generation > Custom comments pane in the Configuration Parameters dialog box or set the parameter
ReqsInCode to on . |
The option to generate nonfinite data and operations is selected. Support for nonfinite numbers is inappropriate for real-time embedded systems. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.) | Clear Support: non-finite numbers (Simulink Coder) on the Code Generation > Interface pane in the Configuration Parameters dialog box or set the parameter
SupportNonFinite to off . |
The option to generate and maintain integer counters for absolute and elapsed time is selected. Support for absolute time is inappropriate for real-time safety-related systems. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.) | Clear Support: absolute
time (Embedded Coder) on the Code Generation > Interface pane in the Configuration Parameters dialog box or set the parameter
SupportAbsoluteTime to off . |
The option to generate code for blocks that use continuous time is selected. Support for continuous time is inappropriate for real-time safety-related systems. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.) | Clear Support: continuous
time (Embedded Coder) on the Code Generation > Interface pane in the Configuration Parameters dialog box or set the parameter
SupportContinuousTime to off . |
The option to generate code for non-inlined S-functions is selected. This option requires support of nonfinite numbers, which is inappropriate for real-time safety-related systems. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.) | Clear Support non-inlined
S-functions (Embedded Coder)in the Configuration Parameters dialog box or set
the parameter SupportNonInlinedSFcns to
off . |
The option to generate model function calls compatible with the main program module of the pre-R2012a GRT target is selected. This option is inappropriate for real-time safety-related systems. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.) | Clear Classic
call interface (Simulink Coder) on the Code Generation > Interfacepane in the Configuration Parameters dialog box or set the parameter
GRTInterface to off . |
The option to generate the
function is cleared.
Having a single call to the output and update functions simplifies the interface to
the real-time operating system (RTOS) and simplifies verification of the generated
code. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with
target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are
compatible with target computer.) | Select Single output/update function (Simulink Coder) on the Code Generation > Interfacepane in the Configuration Parameters dialog box or set the parameter
CombineOutputUpdateFcns to on . |
The option to generate the
function is
selected. This function deallocates dynamic memory, which is unsuitable for
real-time safety-related systems. (See DO-331, Section MB.6.3.1.c – High-level
requirements are compatible with target computer and DO-331, Section MB.6.3.2.c –
Low-level requirements are compatible with target computer.) | Clear Terminate function (Embedded Coder) on the Code
Generation pane in the Configuration Parameters dialog box or set
the parameter IncludeMdlTerminateFcn to
off . |
The option to log or monitor error status is cleared. If you do not select this option, the Simulink Coder™ product generates extra code that might not be reachable for testing. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.) | Select Remove
error status field in real-time model data structure (Embedded Coder) on the Code Generation > Interface pane in the Configuration Parameters dialog box or set the parameter
SuppressErrorStatus to on . |
MAT-file logging is selected. This option adds extra code for logging test points to a MAT-file, which is not supported by embedded targets. Use this option only in test harnesses. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.) | Clear MAT-file
logging (Simulink Coder) in the Configuration Parameters dialog box or set the
parameter MatFileLogging to off . |
The option that specifies the style for parenthesis usage is set to
Minimum (Rely on C/C++ operators precedence) or to
Nominal (Optimize for readability) . For safety-related
applications, explicitly specify precedence with parentheses. (See DO-331, Section
MB.6.3.1.c – High-level requirements are compatible with target computer, DO-331,
Section MB.6.3.2.c – Low-level requirements are compatible with target computer, and
MISRA C:2012, Rule 12.1.) | Set parameter ParenthesesLevel to Maximum (Specify
precedence with parentheses) . |
The option that specifies whether to preserve operand order is cleared. This option increases the traceability of the generated code. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.) | Set parameter PreserveExpressionOrder to
on . |
The option that specifies whether to preserve empty primary condition
expressions in if statements is cleared. This option increases
the traceability of the generated code. ( See DO-331, Section MB.6.3.4.e – Source
code is traceable to low-level requirements.) | Set parameter PreserveIfCondition to
on . |
The minimum number of characters specified for generating name mangling strings is less than four. You can use this option to minimize the likelihood that parameter and signal names will change during code generation when the model changes. Use of this option assists with minimizing code differences between file versions, decreasing the effort to perform code reviews. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.) | Set Minimum
mangle length (Embedded Coder) on the Code Generation > Identifiers pane in the Configuration Parameters dialog box or the parameter
MangleLength to a value of 4 or greater. |
Clicking Modify Settings configures model code generation settings that can impact safety.
Subchecks depend on the results of the subchecks noted with D in the results table in the Model Advisor window.
Does not run on library models.
Does not allow exclusions of blocks or charts.
hisl_0038: Configuration Parameters > Code Generation > Comments (Simulink)
hisl_0039: Configuration Parameters > Code Generation > Interface (Simulink)
hisl_0047: Configuration Parameters > Code Generation > Code Style (Simulink)
hisl_0049: Configuration Parameters > Code Generation > Identifiers (Simulink)
Model Configuration Parameters: Comments (Simulink Coder)
Model Configuration Parameters: Comments (Simulink Coder)
Model Configuration Parameters: Code Generation Identifiers (Simulink Coder)
Model Configuration Parameters: Code Generation Interface (Simulink Coder)
Model Configuration Parameters: Code Style (Embedded Coder)
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178C Software Considerations in Airborne Systems and Equipment Certification and related standards
Check ID:
mathworks.do178.MathOperationsBlocksUsage
Identify usage of Math Operation blocks that might impact safety.
This check inspects the usage of the following blocks:
Abs
Gain
Math Function
Natural logarithm
Common (base 10) logarithm
Remainder after division
Reciprocal
Assignment
Available with Simulink Check.
Condition | Recommended Action |
---|---|
The model or subsystem contains an Absolute Value block that is operating on one of the following:
|
If the identified Absolute Value block is operating on a boolean or unsigned data type, do one of the following:
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 contains Math Function - Natural
logarithm (log) blocks that might result in non-finite output
signals. Non-finite signals are not supported in real-time embedded systems. |
When using the Math Function block with a
|
The model or subsystem contains Math Function - Common (base
10)(base 10 logarithm) blocks that might result in non-finite
output signals. Non-finite signals are not supported in real-time embedded systems. |
When using the Math Function block with a
|
The model or subsystem contains Math Function - Remainder after
division(rem) blocks that might result in non-finite output
signals. Non-finite signals are not supported in real-time embedded systems. |
When using the Math Function block with a
|
The model or subsystem contains Math Function - Reciprocal
(reciprocal) blocks that might result in non-finite output
signals. Non-finite signals are not supported in real-time embedded systems. |
When using the Math Function block with a
|
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:
|
Does not run on library models.
Analyzes content of library linked blocks.
Analyzes content in all masked subsystems.
Allows exclusions of blocks and charts.
DO-331 Section MB.6.3.1.d – High-level requirements are verifiable
DO-331 Section MB.6.3.2.d – Low-level requirements are verifiable
MISRA C:2012, Dir 4.1
MISRA C:2012, Rule 9.1
hisl_0002: Usage of Math Function blocks (rem and reciprocal)
hisl_0004: Usage of Math Function blocks (natural logarithm and base 10 logarithm)
Check ID:
mathworks.do178.LogicBlockUsage
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, Detect Change, and If blocks
Logical Operator blocks
Available with Simulink Check.
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. | For the identified blocks, use common data types as inputs. You can use Data Type Conversion blocks to change input data types. |
The model or subsystem contains a block computing a relational operator that does not have Boolean output. The condition can lead to unpredictable results in the generated code. | For the specified blocks, on the Block Parameters > Signal Attributes pane, set the Output data type to
boolean . |
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. |
|
Does not run on library models.
Analyzes content of library linked blocks.
Analyzes content in all masked subsystems.
Allows exclusions of blocks and charts.
DO-331, Sections MB.6.3.1.g and MB.6.3.2.g - Algorithms are accurate
MISRA C:2012, Dir 1.1
MISRA C:2012, Rule 10.1
hisl_0016: Usage of blocks that compute relational operators (Simulink)
hisl_0017: Usage of blocks that compute relational operators (2) (Simulink)
hisl_0018: Usage of Logical Operator block (Simulink)
Check ID:
mathworks.do178.PortsSubsystemsUsage
Identify usage of Ports and Subsystems blocks that might impact safety.
This check inspects the usage of these blocks:
For Iterator
While Iterator
If
Switch Case
The check does not flag Switch Case blocks that do not use integer data types or enumeration values for inputs. To comply with hisl_0011: Usage of Switch Case blocks and Action Subsystem blocks (Simulink) – C, use an integer data type or an enumeration value for the inputs to Switch Case blocks.
Available with Simulink Check.
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 a 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:
| In the model or subsystem, consider removing the time-dependent blocks. |
Does not run on library models.
Analyzes content of library linked blocks.
Analyzes content in all masked subsystems.
Allows exclusions of blocks and charts.
DO-331, Section MB.6.3.3.b—Software architecture is consistent
DO-331, Sections MB.6.3.1.g and MB.6.3.2.g - Algorithms are accurate
DO-331, Section MB.6.3.1.e – High-level requirements conform to standards
DO-331, Section MB.6.3.2.e – Low-level requirements conform to standards
DO-331, Section MB.6.3.1.b - High-level requirements are accurate and consistent
DO-331, Section MB.6.3.2.b - Low-level requirements are accurate and consistent
MISRA C:2012, Rule 14.2
MISRA C:2012, Rule 16.4
MISRA C:2012, Dir 4.1
hisl_0006: Usage of While Iterator blocks (Simulink)
hisl_0007: Usage of For Iterator or While Iterator subsystems (Simulink)
hisl_0008: Usage of For Iterator Blocks (Simulink)
hisl_0011: Usage of Switch Case blocks and Action Subsystem blocks (Simulink)
Check ID:
mathworks.do178.MdlChecksum
Display model version information in your report.
This check displays the following information for the current model:
Version number
Author
Date
Model checksum
Available with Simulink Check.
Condition | Recommended Action |
---|---|
Could not retrieve model version and checksum information. | This summary is provided for your information. No action is required. |
Does not run on library models.
Does not allow exclusions of blocks or charts.
Reports for Code Generation (Simulink Coder)
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178C Software Considerations in Airborne Systems and Equipment Certification and related standards