| 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.
Consulting Model Advisor in the Simulink documentation
Simulink® Checks in the Simulink 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-critical 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 on. 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. |
| Conditional input branch execution is on. Because the model coverage tool does not account for this optimization, the optimization can result in the tool reporting 100% model coverage while coverage for the code using the same test cases can be less than 100%. (See DO-178B, Section 6.4.4.2 – Test coverage of software structure is achieved.) | Clear the Conditional input branch execution check box on the Optimization pane of the Configuration Parameters dialog box or set the parameter ConditionallyExecuteInputs to off. |
| Implementation of logic signals as Boolean data is off. Strong data typing is recommended for safety-critical 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 the parameter LifeSpan to inf. |
| The optimization that ignores integer downcasts in folded expressions is on. This optimization can remove blocks that typecast data from generated code, resulting in requirements with no associated code and violations for traceability requirements. (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.) | 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 off. |
| The optimization that suppresses the generation of initialization code for root-level inports and outports that are set to zero is on. For safety-critical 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.) | 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 on. For safety-critical 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.) | Clear the Remove internal state 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 off. You must avoid overflows for safety-critical 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.) | 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 specifies whether to generate code that guards against division by zero for fixed-point data is on. You must avoid division-by-zero exceptions in safety-critical 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.) | 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. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to solvers are set optimally for generating code for a safety-critical 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-critical 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 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-critical 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 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-critical 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 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 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-critical 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 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-critical 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 the parameter StateNameClashWarn to warning. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to sample times are set optimally for generating code for a safety-critical 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-critical 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 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 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 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 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 the parameter SigSpecEnsureSampleTimeMsg to error. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to signal data are set optimally for generating code for a safety-critical 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-critical 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 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-critical 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 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-critical 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 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 incorrect and unsafe 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 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-critical 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 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, DO-178B and 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 the parameter RTPrefix to error. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to parameters are set optimally for generating code for a safety-critical 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 incorrect and unsafe 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 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 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 incorrect and unsafe application behavior and should be detected and corrected in safety-critical 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 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 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 the parameter ParameterTunabilityLossMsg to error. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to debugging are set optimally for generating code for a safety-critical 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 the parameter AssertControl to Disable All. |
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 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-critical 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 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 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 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 the parameter MultiTaskDSMMsg to error. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to type conversions are set optimally for generating code for a safety-critical 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 warning can result in requirements with no 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 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 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 the parameter Int32ToFloatConvMsg to warning. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to signal connectivity are set optimally for generating code for a safety-critical 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 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 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 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 the parameter UnconnectedLineMsg to error. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to bus connectivity are set optimally for generating code for a safety-critical 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 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 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. | Set Mux blocks used to create bus signals on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or the parameter StrictBusMsg to error. 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. |
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 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-critical 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 the parameter InvalidFcnCallConMsg to error. |
| The diagnostic that specifies whether the Simulink software has to compute a function-call subsystem's inputs 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 subsystem's inputs. | Set Context-dependent inputs on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or the parameter FcnCallInpInsideContextMsg to Enable all. |
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 can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to compatibility are set optimally for generating code for a safety-critical 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 the parameter SFcnCompatibilityMsg to error. |
| The Check undefined subsystem initial output diagnostic is off. 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. | Set Check undefined subsystem initial output on the Diagnostics > Compatibility pane of the Configuration Parameters dialog box or the parameter CheckSSInitialOutputMsg to on. |
| The diagnostic that detects potential initial output differences from earlier releases is set to off. An output of a conditionally executed subsystem could have an output that is not initialized. If undetected, this condition can produce behavior that is nondeterministic. | Set Check preactivation output of execution context on the Diagnostics > Compatibility pane of the Configuration Parameters dialog box or the parameter CheckExecutionContextPreStartOutputMsg to on. |
| The diagnostic that detects potential output differences from earlier releases is set to off. An output of 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. | Set Check runtime output of execution context on the Diagnostics > Compatibility pane of the Configuration Parameters dialog box or the parameter CheckExecutionContextRuntimeOutputMsg to on. |
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
Check model configuration for diagnostic settings that apply to model referencing and can impact safety.
This check verifies that model diagnostic configuration parameters pertaining to model referencing are set optimally for generating code for a safety-critical 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 referenced model's current version is set to none or warning. The detection occurs during load and update operations. Get the latest version of the referenced model from the software configuration management system, rather than using an older version. Using an older version can produce incorrect simulation results and mismatches between simulation and target code operation. (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 the parameter ModelReferenceVersionMismatchMessage to error. |
| 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 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 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 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. Because To Workspace and Scope blocks are for debugging and not for embedded code, it is best to detect the condition so model developers can correct it. (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 the parameter ModelReferenceDataLoggingMessage to error. |
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
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-critical 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 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-critical 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 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 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 the parameter ModelReferenceMinAlgLoopOccurrences to off. |
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-critical application.
| Condition | Recommended Action |
|---|---|
| The option to include comments in the generated code is off. 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.) | Set Include comments on the Real-Time Workshop > Comments pane of the Configuration Parameters dialog box or the parameter GenerateComments to on. |
| The option to include comments that describe the code for blocks is off. 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.) | Set Simulink block / Stateflow object comments on the Real-Time Workshop > Comments pane of the Configuration Parameters dialog box or the parameter SimulinkBlockComments to on. |
| The option to include comments that describe the code for blocks eliminated from a model is off. 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.) | Set Show eliminated blocks on the Real-Time Workshop > Comments pane of the Configuration Parameters dialog box or 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 off. 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.) | Set Verbose comments for SimulinkGlobal storage class on the Real-Time Workshop > Comments pane of the Configuration Parameters dialog box or the parameter ForceParamTrailComments to on. |
| The option to include requirement descriptions assigned to Simulink blocks as comments is off. 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.) | Set Requirements in block comments on the Real-Time Workshop > Comments pane of the Configuration Parameters dialog box or the parameter ReqsInCode to on. |
| The option to generate nonfinite data and operations is on. Support for nonfinite numbers is inappropriate for real-time safety-critical 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.) | Set Support: non-finite numbers on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter SupportNonFinite to off. |
| The option to generate and maintain integer counters for absolute and elapsed time is on. Support for absolute time is inappropriate for real-time safety-critical 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.) | Set Support: absolute time on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter SupportAbsoluteTime to off. |
| The option to generate code for blocks that use continuous time is on. Support for continuous time is inappropriate for real-time safety-critical 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.) | Set Support: continuous time on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter SupportContinuousTime to off. |
| The option to generate code for noninlined S-functions is on. This option requires support of nonfinite numbers, which is inappropriate for real-time safety-critical 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.) | Set Support: non-inlined S-functions on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter SupportNonInlinedSFcns to off. |
| The option to generate model function calls compatible with the main program module of the GRT target is on. This option is inappropriate for real-time safety-critical 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.) | Set GRT compatible call interface on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter GRTInterface to off. |
| The option to generate the model_update function is off. 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.) | Set Single output/update function on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter CombineOutputUpdateFcns to on. |
| The option to generate the model_terminate function is on. This function deallocates dynamic memory, which is not appropriate for real-time safety-critical 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.) | Set Terminate function required on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter IncludeMdlTerminateFcn to off. |
| The option to log or monitor error status is off. 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.) | Set Suppress error status in real-time model data structure on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter SuppressErrorStatus to on. |
| MAT-file logging is enabled. 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.) | Set MAT-file logging on the Real-Time Workshop > Interface pane of the Configuration Parameters dialog box or the parameter MatFileLogging to on. |
| 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-critical 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 the parameter ParenthesisStyle to Maximum (Specify precedence with parentheses). |
| The option that specifies whether to preserve operand order is off. This option increases the traceability of the generated code. (See DO-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Set Preserve operand order in expression on the Real-Time Workshop > Code pane of the Configuration Parameters dialog box or the parameter PreserveExpressionOrder to on. |
| The option that specifies whether to preserve empty primary condition expressions in if statements is off. This option increases the traceability of the generated code. ( See DO-178B, Section 6.3.4e – Source code is traceable to low-level requirements.) | Set Preserve condition expression in if statement on the Real-Time Workshop > Code pane of the Configuration Parameters dialog box or 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. |
| The maximum number of characters specified for generated function, type definition, and variable names is less than 31. You should set this option based on the maximum value allowed by the compiler being used. The longer the length can be, the easier it is to trace identifiers to the model. (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 Maximum identifier length on the Real-Time Workshop > Symbols pane of the Configuration Parameters dialog box or the parameter MaxIdLength to a value of 31 or greater. |
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 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
Validate 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 | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |