Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink Verification and Validation |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Simulink Verification and Validation |
| Contents | Index |
| Learn more about Simulink Verification and Validation |
DO-178B 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 Verification and Validation license when you run the DO-178B checks.
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
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for optimization settings that can impact safety.
This check verifies that model optimization configuration parameters are set optimally for generating code for a safety-related application. Although highly optimized code is desirable for most real-time systems, some optimizations can have undesirable side effects that impact safety.
| Condition | Recommended Action |
|---|---|
| Block reduction optimization is selected. This optimization can remove blocks from generated code, resulting in requirements with no associated code and violations for traceability requirements. (See DO-178B, Section 6.3.4e—Source code is traceable to low-level requirements.) | Clear the Block reduction check box on the Optimization pane of the Configuration Parameters dialog box or set the parameter BlockReduction to off. |
| Implementation of logic signals as Boolean data is cleared. Strong data typing is recommended for safety-related code. (See DO-178B, Section 6.3.1e—High-level requirements conform to standards, DO-178B, Section 6.3.2e—Low-level requirements conform to standards, and MISRA C® 2004, Rule 12.6.) | Select Implement logic signals as boolean data (vs. double) on the Optimization pane of the Configuration Parameters dialog box or set the parameter BooleanDataType to on. |
| The model includes blocks that depend on elapsed or absolute time and is configured to minimize the amount of memory allocated for the timers. Such a configuration limits the number of days the application can execute before a timer overflow occurs. Many aerospace products are powered on continuously and timers should not assume a limited lifespan. (See DO-178B, Section 6.3.1g—Algorithms are accurate, DO-178B, Section 6.3.2g—Algorithms are accurate, and MISRA C 2004, Rule 12.11.) | Set Application lifespan (days) on the Optimization pane of the Configuration Parameters dialog box or set the parameter LifeSpan to inf. |
| The optimization that ignores integer downcasts in folded expressions is selected. This optimization can remove blocks that typecast data from generated code, resulting in incorrect behavior due to overflows of integer data and requirements without associated code. (See DO-178B, Section 6.3.1g—Algorithms are accurate, DO-178B, Section 6.3.2g—Algorithms are accurate, and MISRA C 2004, Rule 10.1.) | If you have a Real-Time Workshop license, clear the Ignore integer downcasts in folded expressions check box on the Optimization pane of the Configuration Parameters dialog box or set the parameter EnforceIntegerDowncast to on. |
| The optimization that suppresses the generation of initialization code for root-level inports and outports that are set to zero is selected. For safety-related code, you should explicitly initialize all variables. (See DO-178B, Section 6.3.3b—Software architecture is consistent and MISRA C 2004, Rule 9.1.) | If you have a Real-Time Workshop Embedded Coder license, and you are using an ERT-based system target file, clear the Remove root level I/O zero initialization check box on the Optimization pane of the Configuration Parameters dialog box or set the parameter ZeroExternalMemoryAtStartup to on. Alternatively, integrate external, hand-written code that initializes all I/O variables to zero explicitly. |
| The optimization that suppresses the generation of initialization code for internal work structures, such as block states and block outputs that are set to zero, is selected. For safety-related code, you should explicitly initialize all variables. (See DO-178B, Section 6.3.3b—Software architecture is consistent and MISRA C 2004, Rule 9.1.) | If you have a Real-Time Workshop Embedded Coder license, and you are using an ERT-based system target file, clear the Remove internal data zero initialization check box on the Optimization pane of the Configuration Parameters dialog box or set the parameter ZeroInternalMemoryAtStartup to on. Alternatively, integrate external, hand-written code that initializes all state variables to zero explicitly. |
| The optimization that suppresses generation of code resulting from floating-point to integer conversions that wrap out-of-range values is cleared. You must avoid overflows for safety-related code. When this optimization is off and your model includes blocks that disable the Saturate on overflow parameter, the code generator wraps out-of-range values for those blocks. This can result in unreachable and, therefore, untestable code. (See DO-178B, Section 6.3.1g—Algorithms are accurate, DO-178B, Section 6.3.2g—Algorithms are accurate, and MISRA C 2004, Rule 12.11.) | If you have a Real-Time Workshop license, select Remove code from floating-point to integer conversions that wraps out-of-range values on the Optimization pane of the Configuration Parameters dialog box or set the parameter EfficientFloat2IntCast to on. |
| The optimization that suppresses generation of code that guards against division by zero for fixed-point data is selected. You must avoid division-by-zero exceptions in safety-related code. (See DO-178B, Section 6.3.1g—Algorithms are accurate, DO-178B, Section 6.3.2g—Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | If you have a Real-Time Workshop Embedded Coder license, and you are using an ERT-based system target file, clear the Remove code that protects against division arithmetic exceptions check box on the Optimization pane of the Configuration Parameters dialog box or set the parameter NoFixptDivByZeroProtection to off. |
Clicking Modify Settings configures model optimization settings that can impact safety.
Optimization Pane in the Simulink graphical user interface documentation
Optimizing a Model for Code Generation in the Real-Time Workshop documentation
Tips for Optimizing the Generated Code in the Real-Time Workshop Embedded Coder documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to solvers and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to solvers are set optimally for generating code for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The diagnostic for detecting automatic breakage of algebraic loops is set to none or warning. The breaking of algebraic loops can affect the predictability of the order of block execution. For safety-related applications, a model developer needs to know when such breaks occur. (See DO-178B, Section 6.3.3e – Software architecture conforms to standards.) | Set Algebraic loop on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter AlgebraicLoopMsg to error. Consider breaking such loops explicitly with Unit Delay blocks to ensure that execution order is predictable. At a minimum, verify that the results of loops breaking automatically are acceptable. |
| The diagnostic for detecting automatic breakage of algebraic loops for Model blocks, atomic subsystems, and enabled subsystems is set to none or warning. The breaking of algebraic loops can affect the predictability of the order of block execution. For safety-related applications, a model developer needs to know when such breaks occur. (See DO-178B, Section 6.3.3e – Software architecture conforms to standards.) | Set Minimize algebraic loop on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter ArtificialAlgebraicLoopMsg to error. Consider breaking such loops explicitly with Unit Delay blocks to ensure that execution order is predictable. At a minimum, verify that the results of loops breaking automatically are acceptable. |
| The diagnostic for detecting potential conflict in block execution order is set to none or warning. For safety-related applications, block execution order must be predictable. A model developer needs to know when conflicting block priorities exist. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Block priority violation on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter BlockPriorityViolationMsg to error. |
| The diagnostic for detecting whether a model contains an S-function that has not been specified explicitly to inherit sample time is set to none or warning. These settings can result in unpredictable behavior. A model developer needs to know when such an S-function exists in a model so it can be modified to produce predictable behavior. (See DO-178B, Section 6.3.3e – Software architecture conforms to standards.) | Set Unspecified inheritability of sample times on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter UnknownTslnhSupMsg to error. |
| The diagnostic for detecting whether the Simulink software automatically modifies the solver, step size, or simulation stop time is set to none or warning. Such changes can affect the operation of generated code. For safety-related applications, it is better to detect such changes so a model developer can explicitly set the parameters to known values. (See DO-178B, Section 6.3.3e – Software architecture conforms to standards.) | Set Automatic solver parameter selection on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter SolverPrmCheckMsg to error. |
| The diagnostic for detecting when a name is used for more than one state in the model is set to none. State names within a model should be unique. For safety-related applications, it is better to detect name clashes so a model developer can correct them. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set State name clash on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter StateNameClashWarn to warning. |
Clicking Modify Settings configures model diagnostic settings that apply to solvers and that can impact safety.
Diagnostics Pane: Solver in the Simulink graphical user interface documentation
Diagnosing Simulation Errors in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to sample time and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to sample times are set optimally for generating code for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The diagnostic for detecting when a source block, such as a Sine Wave block, inherits a sample time (specified as -1) is set to none or warning. The use of inherited sample times for a source block can result in unpredictable execution rates for the source block and blocks connected to it. For safety-related applications, source blocks should have explicit sample times to prevent incorrect execution sequencing. (See DO-178B, Section 6.3.3e – Software architecture conforms to standards.) | Set Source block specifies -1 sample time on the Diagnostics > Sample Time pane of the Configuration Parameters dialog box or set the parameter InheritedTslnSrcMsg to error. |
| The diagnostic for detecting whether the input for a discrete block, such as the Unit Delay block, is a continuous signal is set to none or warning. Signals with continuous sample times should not be used for embedded real-time code. (See DO-178B, Section 6.3.3e – Software architecture conforms to standards.) | Set Discrete used as continuous on the Diagnostics > Sample Time pane of the Configuration Parameters dialog box or set the parameter DiscreteInheritContinuousMsg to error. |
| The diagnostic for detecting invalid rate transitions between two blocks operating in multitasking mode is set to none or warning. Such rate transitions should not be used for embedded real-time code. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Multitask rate transition on the Diagnostics > Sample Time pane of the Configuration Parameters dialog box or set the parameter MultiTaskRateTransMsg to error. |
| The diagnostic for detecting subsystems that can cause data corruption or nondeterministic behavior is set to none or warning. This diagnostic detects whether conditionally executed multirate subsystems (enabled, triggered, or function-call subsystems) operate in multitasking mode. Such subsystems can corrupt data and behave unpredictably in real-time environments that allow preemption. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Multitask conditionally executed subsystem on the Diagnostics > Sample Time pane of the Configuration Parameters dialog box or set the parameter MultiTaskCondExecSysMsg to error. |
| The diagnostic for checking sample time consistency between a Signal Specification block and the connected destination block is set to none or warning. An over-specified sample time can result in an unpredictable execution rate. (See DO-178B, Section 6.3.3e – Software architecture conforms to standards.) | Set Enforce sample times specified by Signal Specification blocks on the Diagnostics > Sample Time pane of the Configuration Parameters dialog box or set the parameter SigSpecEnsureSampleTimeMsg to error. |
Clicking Modify Settings configures model diagnostic settings that apply to sample time and that can impact safety.
Diagnostics Pane: Sample Time in the Simulink graphical user interface documentation
Diagnosing Simulation Errors in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to signal data and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to signal data are set optimally for generating code for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The diagnostic that specifies how the Simulink software resolves signals associated with Simulink.Signal objects in the MATLAB workspace is set to Explicit and implicit or Explicit and warn implicit. For safety-related applications, model developers should be required to define signal resolution explicitly. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Signal resolution on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter SignalResolutionControl to Explicit only. This provides predictable operation by requiring users to define each signal and block setting that must resolve to Simulink.Signal objects in the workspace. |
| The Product block diagnostic that detects a singular matrix while inverting one of its inputs in matrix multiplication mode is set to none or warning. Division by a singular matrix can result in numeric exceptions when executing generated code. This is not acceptable in safety-related systems. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | Set Division by singular matrix on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter CheckMatrixSingularityMsg to error. |
| The diagnostic that detects when the Simulink software cannot infer the data type of a signal during data type propagation is set to none or warning. For safety-related applications, model developers must ensure that all data types are specified correctly. (See DO-178B, Section 6.3.1e – High-level requirements conform to standards, DO-178B and Section 6.3.2e – Low-level requirements conform to standards.) | Set Underspecified data types on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter UnderSpecifiedDataTypeMsg to error. |
| The diagnostic that detects whether the value of a signal or parameter is too large to be represented by the signal or parameter's data type is set to none or warning. Undetected numeric overflows can result in unexpected application behavior. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | Set Detect overflow on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter IntegerOverflowMsg to error. |
| The diagnostic that detects when the value of a block output signal is Inf or NaN at the current time step is set to none or warning. When this type of block output signal condition occurs, numeric exceptions can result, and numeric exceptions are not acceptable in safety-related applications. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | Set Inf or NaN block output on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter SignalInfNanChecking to error. |
| The diagnostic that detects Simulink object names that begin with rt is set to none or warning. This diagnostic prevents name clashes with generated signal names that have an rt prefix. (See DO-178B, Section 6.3.1e – High-level requirements conform to standards, and DO-178B, Section 6.3.2e – Low-level requirements conform to standards.) | Set "rt" prefix for identifiers on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter RTPrefix to error. |
| The diagnostic that detects simulation range checking is set to none or warning. This diagnostic detects when signals exceed their specified ranges during simulation. Simulink compares the signal values that a block outputs with the specified range and the block data type. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | Set Simulation range checking on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter SignalRangeChecking to error. |
Clicking Modify Settings configures model diagnostic settings that apply to signal data and that can impact safety.
Diagnostics Pane: Data Validity in the Simulink graphical user interface documentation
Diagnosing Simulation Errors in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to parameters and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to parameters are set optimally for generating code for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects when a parameter downcast occurs is set to none or warning. A downcast to a lower signal range can result in numeric overflows of parameters, resulting in unexpected behavior. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | Set Detect downcast on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter ParameterDowncastMsg to error. |
| The diagnostic that detects when a parameter underflow occurs is set to none or warning. When the data type of a parameter does not have sufficient resolution, the parameter value is zero instead of the specified value. This can lead to incorrect operation of generated code. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | Set Detect underflow on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter ParameterUnderflowMsg to error. |
| The diagnostic that detects when a parameter overflow occurs is set to none or warning. Numeric overflows can result in unexpected application behavior and should be detected and corrected in safety-related applications. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rule 21.1.) | Set Detect overflow on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter ParameterOverflowMsg to error. |
| The diagnostic that detects when a parameter loses precision is set to none or warning. Not detecting such errors can result in a parameter being set to an incorrect value in the generated code. (See DO-178B, Section 6.3.1g – Algorithms are accurate, DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rules 10.1, 10.2, 10.3, and 10.4.) | Set Detect precision loss on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter ParameterPrecisionLossMsg to error. |
| The diagnostic that detects when an expression with tunable variables is reduced to its numerical equivalent is set to none or warning. This can result in a tunable parameter unexpectedly not being tunable in generated code. (See DO-178B, Section 6.3.1g – Algorithms are accurate and DO-178B, Section 6.3.2g – Algorithms are accurate.) | Set Detect loss of tunability on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter ParameterTunabilityLossMsg to error. |
Clicking Modify Settings configures model diagnostic settings that apply to parameters and that can impact safety.
Diagnostics Pane: Data Validity in the Simulink graphical user interface documentation
Diagnosing Simulation Errors in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to data used for debugging and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to debugging are set optimally for generating code for a safety-related application.
See
DO-178B, Section 6.3.1e – High-level requirements conform to standards
DO-178B and Section 6.3.2e – Low-level requirements conform to standards
| Condition | Recommended Action |
|---|---|
| The diagnostic that enables model verification blocks is set to Use local settings or Enable all. Such blocks should be disabled because they are assertion blocks, which are for verification only. Model developers should not use assertions in embedded code. | Set Model Verification block enabling on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter AssertControl to Disable All. |
Clicking Modify Settings configures model diagnostic settings that apply to data used for debugging and that can impact safety.
Diagnostics Pane: Data Validity in the Simulink graphical user interface documentation
Diagnosing Simulation Errors in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to data store memory and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to data store memory are set optimally for generating code for a safety-related application.
See DO-178B, Section 6.3.3b – Software architecture is consistent.
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects whether the model attempts to read data from a data store in which it has not stored data in the current time step is set to a value other than Enable all as errors. Reading data before it is written can result in use of stale data or data that is not initialized. | Set Detect read before write on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter ReadBeforeWriteMsg to Enable all as errors. |
| The diagnostic that detects whether the model attempts to store data in a data store, after previously reading data from it in the current time step, is set to a value other than Enable all as errors. Writing data after it is read can result in use of stale or incorrect data. | Set Detect write after read on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter WriteAfterReadMsg to Enable all as errors. |
| The diagnostic that detects whether the model attempts to store data in a data store twice in succession in the current time step is set to a value other than Enable all as errors. Writing data twice in one time step can result in unpredictable data. | Set Detect write after write on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter WriteAfterWriteMsg to Enable all as errors. |
| The diagnostic that detects when one task reads data from a Data Store Memory block to which another task writes data is set to none or warning. Reading or writing data in different tasks in multitask mode can result in corrupted or unpredictable data. | Set Multitask data store on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter MultiTaskDSMMsg to error. |
Clicking Modify Settings configures model diagnostic settings that apply to data store memory and that can impact safety.
Diagnostics Pane: Data Validity in the Simulink graphical user interface documentation
Diagnosing Simulation Errors in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to type conversions and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to type conversions are set optimally for generating code for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects Data Type Conversion blocks used where no type conversion is necessary is set to none. The Simulink software might remove unnecessary Data Type Conversion blocks from generated code. This might result in requirements without corresponding code. The removal of such blocks need to be detected so model developers can remove the unnecessary blocks explicitly. (See DO-178B, Section 6.3.1g – Algorithms are accurate and DO-178B, Section 6.3.2g – Algorithms are accurate.) | Set Unnecessary type conversions on the Diagnostics > Type Conversion pane of the Configuration Parameters dialog box or set the parameter UnnecessaryDatatypeConvMsg to warning. |
| The diagnostic that detects vector-to-matrix or matrix-to-vector conversions at block inputs is set to none or warning. When the Simulink software automatically converts between vector and matrix dimensions, unintended operations or unpredictable behavior can occur. (See DO-178B, Section 6.3.1g – Algorithms are accurate and DO-178B, Section 6.3.2g – Algorithms are accurate.) | Set Vector/matrix block input conversion on the Diagnostics > Type Conversion pane of the Configuration Parameters dialog box or set the parameter VectorMatrixConversionMsg to error. |
| The diagnostic that detects when a 32-bit integer value is converted to a floating-point value is set to none. This type of conversion can result in a loss of precision due to truncation of the least significant bits for large integer values. (See DO-178B, Section 6.3.1g – Algorithms are accurate and DO-178B, Section 6.3.2g – Algorithms are accurate, and MISRA C 2004, Rules 10.1, 10.2, 10.3, and 10.4.) | Set 32-bit integer to single precision float conversion on the Diagnostics > Type Conversion pane of the Configuration Parameters dialog box or set the parameter Int32ToFloatConvMsg to warning. |
Clicking Modify Settings configures model diagnostic settings that apply to type conversions and that can impact safety.
Diagnostics Pane: Type Conversion in the Simulink graphical user interface documentation
Data Type Conversion block in the Simulink reference documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to signal connectivity and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to signal connectivity are set optimally for generating code for a safety-related application.
See
DO-178B, Section 6.3.1e – High-level requirements conform to standards
DO-178B, Section 6.3.2e – Low-level requirements conform to standards
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects virtual signals that have a common source signal but different labels is set to none or warning. This diagnostic pertains to virtual signals only and has no effect on generated code. However, signal label mismatches can lead to confusion during model reviews. | Set Signal label mismatch on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter SignalLabelMismatchMsg to error. |
| The diagnostic that detects when the model contains a block with an unconnected input signal is set to none or warning. This must be detected because code is not generated for unconnected block inputs. | Set Unconnected block input ports on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter UnconnectedInputMsg to error. |
| The diagnostic that detects when the model contains a block with an unconnected output signal is set to none or warning. This must be detected because dead code can result from unconnected block output signals. | Set Unconnected block output ports on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter UnconnectedOutputMsg to error. |
| The diagnostic that detects unconnected signal lines and unmatched Goto or From blocks is set to none or warning. This error must be detected because code is not generated for unconnected lines. | Set Unconnected line on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter UnconnectedLineMsg to error. |
Clicking Modify Settings configures model diagnostic settings that apply to signal connectivity and that can impact safety.
Diagnostics Pane: Connectivity in the Simulink graphical user interface documentation
Signal Basics in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to bus connectivity and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to bus connectivity are set optimally for generating code for a safety-related application.
See DO-178B, Section 6.3.3b – Software architecture is consistent.
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects whether a Model block's root Outport block is connected to a bus but does not specify a bus object is set to none or warning. For a bus signal to cross a model boundary, the signal must be defined as a bus object to ensure compatibility with higher level models that use a model as a reference model. | Set Unspecified bus object at root Outport block on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter RootOutportRequireBusObject to error. |
| The diagnostic that detects whether the name of a bus element matches the name specified by the corresponding bus object is set to none or warning. This diagnostic prevents the use of incompatible buses in a bus-capable block such that the output names are inconsistent. | Set Element name mismatch on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter BusObjectLabelMismatch to error. |
| The diagnostic that detects when some blocks treat a signal as a mux/vector, while other blocks treat the signal as a bus, is set to none or warning. When the Simulink software automatically converts a muxed signal to a bus, it is possible for an unintended operation or unpredictable behavior to occur. |
You can use the Model Advisor or the sl_replace_mux utility function to replace all Mux blocks used as bus creators with a Bus Creator block. |
Clicking Modify Settings configures model diagnostic settings that apply to bus connectivity and that can impact safety.
Diagnostics Pane: Connectivity in the Simulink graphical user interface documentation
Simulink.Bus in the Simulink reference documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to function-call connectivity and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to function-call connectivity are set optimally for generating code for a safety-related application.
DO-178B, Section 6.3.3b – Software architecture is consistent
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects incorrect use of a function-call subsystem is set to none or warning. If this condition is undetected, incorrect code might be generated. | Set Invalid function-call connection on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter InvalidFcnCallConMsg to error. |
| The diagnostic that specifies whether the Simulink software has to compute inputs of a function-call subsystem directly or indirectly while executing the subsystem is set to Use local settings or Disable all. This diagnostic detects unpredictable data coupling between a function-call subsystem and the inputs of the subsystem in the generated code. | Set Context-dependent inputs on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter FcnCallInpInsideContextMsg to Enable all. |
Clicking Modify Settings configures model diagnostic settings that apply to function-call connectivity and that can impact safety.
Diagnostics Pane: Connectivity in the Simulink graphical user interface documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that affect compatibility and that might impact safety.
This check verifies that model diagnostic configuration parameters pertaining to compatibility are set optimally for generating code for a safety-related application.
See DO-178B, Section 6.3.3b – Software architecture is consistent and MISRA C 2004, Rule 9.1.
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects when a block has not been upgraded to use features of the current release is set to none or warning. An S-function written for an earlier version might not be compatible with the current version and generated code could operate incorrectly. | Set S-function upgrades needed on the Diagnostics > Compatibility pane of the Configuration Parameters dialog box or set the parameter SFcnCompatibilityMsg to error. |
Clicking Modify Settings configures model diagnostic settings that affect compatibility and that might impact safety.
Diagnosing Simulation Errors in the Simulink documentation
Diagnostics Pane: Compatibility in the Simulink graphical user interface documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
In the model configuration, check diagnostic settings that affect model initialization and might impact safety.
This check verifies that model diagnostic configuration parameters pertaining to initialization are set optimally for generating code for a safety-related application.
See DO-178B, Section 6.3.3b – Software architecture is consistent and MISRA C 2004, Rule 9.1.
| Condition | Recommended Action |
|---|---|
| The Check undefined subsystem initial output diagnostic is cleared. This diagnostic specifies whether the Simulink software displays a warning if the model contains a conditionally executed subsystem, in which a block with a specified initial condition drives an Outport block with an undefined initial condition. A conditionally executed subsystem could have an output that is not initialized. If undetected, this condition can produce behavior that is nondeterministic. | In the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane, select Check undefined subsystem initial output or set the parameter CheckSSInitialOutputMsg to on. |
| The diagnostic that detects potential initial output differences from earlier releases is cleared. A conditionally executed subsystem could have an output that is not initialized. If undetected, this condition can produce behavior that is nondeterministic. | In the Configuration Parameters dialog box, on the Diagnostics > Compatibility pane, select Check preactivation output of execution context or set the parameter CheckExecutionContextPreStartOutputMsg to on. |
| The diagnostic that detects potential output differences from earlier releases is cleared. A conditionally executed subsystem could have an output that is not initialized and feeds into a block with a tunable parameter. If undetected, this condition can cause the behavior of the downstream block to be nondeterministic. | In the Configuration Parameters dialog box, on the Diagnostics > Compatibility pane, select Check runtime output of execution context or set the parameter CheckExecutionContextRuntimeOutputMsg to on. |
To configure the diagnostic settings that affect model initialization and that might impact safety, click Modify Settings.
Diagnosing Simulation Errors in the Simulink documentation
Diagnostics Pane: Data Validity in the Simulink graphical user interface documentation
For information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard, Radio Technical Commission for Aeronautics (RTCA)
Check model configuration for diagnostic settings that apply to model referencing and that can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to model referencing are set optimally for generating code for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects a mismatch between the version of the model that creates or refreshes a Model block and the current version of the referenced model is set to error or warning. The detection occurs during load and update operations. When you get the latest version of the referenced model from the software configuration management system, rather than an older version that was used in a previous simulation, if this diagnostic is set to error, the simulation is aborted. If the diagnostic is set to warning, a warning message is issued. To resolve the issue, the user must resave the model being simulated, which may not be the desired action. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Model block version mismatch on the Diagnostics > Model Referencing pane of the Configuration Parameters dialog box or set the parameter ModelReferenceVersionMismatchMessage to none. |
| The diagnostic that detects port and parameter mismatches during model loading and updating is set to none or warning. If undetected, such mismatches can lead to incorrect simulation results because the parent and referenced models have different interfaces. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Port and parameter mismatch on the Diagnostics > Model Referencing pane of the Configuration Parameters dialog box or set the parameter ModelReferenceIOMismatchMessage to error. |
| The Model configuration mismatch diagnostic is set to none or error. This diagnostic checks whether the configuration parameters of a model referenced by the current model match the current model's configuration parameters or are inappropriate for a referenced model. Some diagnostics for referenced models are not supported in simulation mode. Setting this diagnostic to error can prevent simulations from running. Some differences in configurations can lead to incorrect simulation results and mismatches between simulation and target code generation. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Model configuration mismatch on the Diagnostics > Model Referencing pane of the Configuration Parameters dialog box or set the parameter ModelReferenceCSMismatchMessage to warning. |
| The diagnostic that detects invalid internal connections to the current model's root-level Inport and Outport blocks is set to none or warning. When this condition is detected, the Simulink software might automatically insert hidden blocks into the model to correct the condition. The hidden blocks can result in generated code that has no traceable requirements. Setting the diagnostic to error forces model developers to correct the referenced models manually. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Invalid root Inport/Outport block connection on the Diagnostics > Model Referencing pane of the Configuration Parameters dialog box or set the parameter ModelReferenceIOMessage to error. |
| The diagnostic that detects whether To Workspace or Scope blocks are logging data in a referenced model is set to none or warning. Data logging is not supported for To Workspace and Scope blocks in referenced models. (See DO-178B, Section 6.3.1d – High-level requirements are verifiable and DO-178B, Section 6.3.2d – Low-level requirements are verifiable.) | Set Unsupported
data logging on the Diagnostics > Model Referencing pane of
the Configuration Parameters dialog box or set the parameter ModelReferenceDataLoggingMessage to error. To log data, remove the blocks and log the referenced model signals. For more information, see Logging Referenced Model Signals. |
Clicking Modify Settings configures model diagnostic settings that apply to model referencing and that can impact safety.
Diagnosing Simulation Errors in the Simulink documentation
Diagnostics Pane: Model Referencing in the Simulink graphical user interface documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Logging Referenced Model Signals in the Simulink documentation
Check model configuration for model referencing settings that can impact safety.
This check verifies that model configuration parameters for model referencing are set optimally for generating code for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The referenced model is configured such that its target is rebuilt whenever you update, simulate, or generate code for the model, or if the Simulink software detects any changes in known dependencies. These configuration settings can result in unnecessary regeneration of the code, resulting in changing only the date of the file and slowing down the build process when using model references. (See DO-178B, Section 6.3.1b – High-level requirements are accurate and consistent and DO-178B, Section 6.3.2b – Low-level requirements are accurate and consistent.) | Set Rebuild options on the Model Referencing pane of the Configuration Parameters dialog box or set the parameter UpdateModelReferenceTargets to Never or If any changes detected. |
| The diagnostic that detects whether a target needs to be rebuilt is set to None or Warn if targets require rebuild. For safety-related applications, an error should alert model developers that the parent and referenced models are inconsistent. This diagnostic parameter is available only if Rebuild options is set to Never. (See DO-178B, Section 6.3.1b – High-level requirements are accurate and consistent and DO-178B, Section 6.3.2b – Low-level requirements are accurate and consistent.) | Set Never rebuild targets diagnostic on the Model Referencing pane of the Configuration Parameters dialog box or set the parameter CheckModelReferenceTargetMessage to Error if targets require rebuild. |
| The ability to pass scalar root input by value is on. This capability should be off because scalar values can change during a time step and result in unpredictable data. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Pass scalar root inputs by value on the Model Referencing pane of the Configuration Parameters dialog box or set the parameter ModelReferencePassRootInputsByReference to off. |
| The model is configured to minimize algebraic loop occurrences. This configuration is incompatible with the recommended setting of Single output/update function for embedded systems code. (See DO-178B, Section 6.3.3b – Software architecture is consistent.) | Set Minimize algebraic loop occurrences on the Model Referencing pane of the Configuration Parameters dialog box or set the parameter ModelReferenceMinAlgLoopOccurrences to off. |
Clicking Modify Settings configures model referencing settings that can impact safety.
Model Dependencies in the Simulink documentation
Model Referencing Pane in the Simulink graphical user interface documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
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.
| Condition | Recommended Action |
|---|---|
| The option to include comments in the generated code is cleared. Comments are necessary for good traceability between the code and the model. (See DO-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Select Include comments on the Real-Time Workshop > Comments > pane of 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 are necessary for good traceability between the code and the model. (See DO-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Select Simulink block / Stateflow object comments on the Real-Time Workshop > Comments pane of 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 are necessary for good traceability between the code and the model. (See DO-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Select Show eliminated blocks on the Real-Time Workshop > Comments pane of 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 model_prm.h is cleared. Comments are necessary for good traceability between the code and the model. (See DO-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Select Verbose comments for SimulinkGlobal storage class on the Real-Time Workshop > Comments pane of 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 are necessary for good traceability between the code and the model. (See DO-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Select Requirements in block comments on the Real-Time Workshop > Comments pane of 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-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Clear Support: non-finite numbers on the Real-Time Workshop > Interface pane of 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-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Clear Support: absolute time on the Real-Time Workshop > Interface pane of 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-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Clear Support: continuous time on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or set the parameter SupportContinuousTime to off. |
| The option to generate code for noninlined S-functions is selected. This option requires support of nonfinite numbers, which is inappropriate for real-time safety-related systems. (See DO-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Clear Support: non-inlined S-functions on the Real-Time Workshop > Interface pane of 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 GRT target is selected. This option is inappropriate for real-time safety-related systems. (See DO-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Clear GRT compatible call interface on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or set the parameter GRTInterface to off. |
| The option to generate the model_update 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-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Select Single output/update function on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or set the parameter CombineOutputUpdateFcns to on. |
| The option to generate the model_terminate function is selected. This function deallocates dynamic memory, which is not appropriate for real-time safety-related systems. (See DO-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Clear Terminate function required on the Real-Time Workshop > Interface pane of 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 Real-Time Workshop product generates extra code that might not be reachable for testing. (See DO-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Select Suppress error status in real-time model data structure on the Real-Time Workshop > Interface pane of 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-178B, Section 6.3.1c – High-level requirements are compatible with target computer and DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer.) | Clear MAT-file logging on the Real-Time Workshop > Interface pane of 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-178B, Section 6.3.1c – High-level requirements are compatible with target computer, DO-178B, Section 6.3.2c – Low-level requirements are compatible with target computer, and MISRA C 2004, Rule 12.1.) | Set Parenthesis level on the Real-Time Workshop > Code pane of the Configuration Parameters dialog box or set the 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-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Select Preserve operand order in expression on the Real-Time Workshop > Code pane of the Configuration Parameters dialog box or set the 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-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Select Preserve condition expression in if statement on the Real-Time Workshop > Code pane of the Configuration Parameters dialog box or set the 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-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Set Minimum mangle length on the Real-Time Workshop > Symbols pane of 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.
This check requires a Real-Time Workshop Embedded Coder license and an ERT-based system target file.
Real-Time Workshop Pane: Comments in the Real-Time Workshop reference documentation
Real-Time Workshop Pane: Symbols in the Real-Time Workshop reference documentation
Real-Time Workshop Pane: Interface in the Real-Time Workshop reference documentation
Real-Time Workshop Pane: Code Style in the Real-Time Workshop Embedded Coder reference documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check model configuration for diagnostic settings that apply to saving model files
This check verifies that model configuration parameters are set optimally for saving a model for a safety-related application.
| Condition | Recommended Action |
|---|---|
| The diagnostic that detects whether a model contains disabled library links before the model is saved is set to none or warning. If this condition is undetected, incorrect code might be generated. (See DO-178B, Section 6.3.3b - Software architecture is consistent.) | Set Block diagram contains disabled library links on the Diagnostics > Saving> pane of the Configuration Parameters dialog box or set the parameter SaveWithDisabledLinkMsg to error. |
| The diagnostic that detects whether a model contains library links that are using parameters not in a mask before the model is saved is set to none or warning. If this condition is undetected, incorrect code might be generated. (See DO-178B, Section 6.3.3b - Software architecture is consistent.) | Set Block diagram contains parameterized library links on the Diagnostics > Saving> pane of the Configuration Parameters dialog box or set the parameter SaveWithParameterizedLinkMsg to error. |
Clicking Modify Settings configures model diagnostic settings that apply to saving a model file.
Disabling Links to Library Blocks in the Simulink documentation
Identifying Disabled Library Links in the Simulink documentation
Saving a Model in the Simulink documentation
Model Parameters in the Simulink documentation
Diagnostics Pane: Saving in the Simulink documentation
Check whether Simulink blocks and Stateflow objects link to a requirements document.
This check verifies whether Simulink blocks and Stateflow objects link to a document containing engineering requirements for traceability.
When you run this check, the Model Advisor does not follow library links or look under masks. The Model Advisor reviews all top-level blocks in the system.
Run this check from the top model or subsystem that you want to check.
Check whether math operators require nonfinite number support.
This check verifies that Math Function blocks do not use math operations that need nonfinite number support with real-time embedded targets.
| Condition | Recommended Action |
|---|---|
| Math Function blocks using log (natural logarithm), log10 (base 10 logarithm), and rem (Remainder) operators that require nonfinite number support. (See DO-178B, Section 6.3.1g - Algorithms are accurate, Section 6.3.2g - Algorithms are accurate, and MISRA C 2004, Rule 21.1) | When using the Math Function block with a log or log10 function, you must protect the input to the block in the model such that it is not less then or equal to zero. Otherwise, the output can produce a NaN or –Inf and result in a run-time error in the generated code. When using the Math Function block with a rem function, you must protect the second input to the block such that it is not equal to zero. Otherwise the output can produce a Inf or –Inf and result in a run-time error in the generated code. |
With embedded systems, you must take care when using blocks that could produce nonfinite outputs such as NaN, Inf or –Inf. Your design must protect the inputs to these blocks in order to avoid run-time errors in the embedded system.
Math Function block in the Simulink documentation
Check for For Iterator blocks that have variable loops.
This check verifies that a model does not use variable loops with For Iterator blocks.
See
DO-178B Section 6.3.1e – High-level requirements conform to standards
DO-178B Section 6.3.2e – Low-level requirements conform to standards
MISRA C 2004, Rule 13.6
| Condition | Recommended Action |
|---|---|
| The model combines the use of variable iteration values with a For Iterator block. The use of variable for loops can lead to unpredictable execution time and, in the case of external iteration variables, infinite loops. | To avoid the use of variable for loops, do one of the following:
|
For Iterator Subsystem block in the Simulink reference documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check for While Iterator blocks that cause infinite loops.
This check verifies that a model does not include infinite loops with While Iterator blocks.
See
DO-178B Section 6.3.1e – High-level requirements conform to standards
DO-178B Section 6.3.2e – Low-level requirements conform to standards
MISRA C 2004, Rule 21.1
| Condition | Recommended Action |
|---|---|
| The model combines the use of a While Iterator block with an unlimited number of iterations. An unlimited number of iterations can lead to infinite loops in real-time code, which can lead to execution time overruns. | To avoid infinite loops:
|
While Iterator Subsystem block in the Simulink reference documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Display model version information in your report.
This check displays the following information for the current model:
Version number
Author
Date
Model checksum
| Condition | Recommended Action |
|---|---|
| Could not retrieve model version and checksum information. | This summary is provided for your information. No action is required. |
Validating Generated Code in the Real-Time Workshop documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check for absolute value blocks that have unreachable code or produce overflows.
This check verifies whether the model includes a block that attempts to compute the absolute value of a Boolean or unsigned integer value.
See
DO-178B Section 6.3.1d – High-level requirements are verifiable
DO-178B Section 6.3.2d – Low-level requirements are verifiable
DO-178B Section 6.3.1g – Algorithms are accurate
DO-178B Section 6.3.2g – Algorithms are accurate
MISRA C 2004, Rule 14.1
MISRA C 2004, Rule 21.1
| Condition | Recommended Action |
|---|---|
The model includes a block that:
|
|
Abs block in the Simulink reference documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
Check for relational operator blocks that compare data types or equate floating-point types.
This check verifies that a model does not use the == or ~= operator with a relational operator block to compare floating-point signals.
See
DO-178B Section 6.3.1g – Algorithms are accurate
DO-178B Section 6.3.2g – Algorithms are accurate
MISRA C 2004, Rule 12.6
MISRA C 2004, Rule 13.3
| Condition | Recommended Action |
|---|---|
| The model includes a relational operator block that uses the == or ~= operator to compare floating-point signals. Because of floating-point precision issues, the use of these operators on floating-point signals is unreliable. | Change the data type of the signal or rework the model to eliminate the need to use the relational operator block with the == or ~= operator. |
Descriptions of the following blocks in the Simulink reference documentation
Relational Operator block in the Simulink reference documentation
Compare To Constant block in the Simulink documentation
Compare To Zero block in the Simulink documentation
Detect Change block in the Simulink documentation
Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178B, Software Considerations in Airborne Systems and Equipment Certification standard
 | Simulink Verification and Validation Checks | IEC 61508 Checks |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
