Documentation Center

  • 評価版
  • 製品アップデート

Contents

DO-178C/DO-331 Checks

DO-178C/DO-331 Checks Overview

DO-178C/DO-331 checks facilitate designing and troubleshooting models from which code is generated for applications that must meet safety or mission-critical requirements.

The Model Advisor performs a checkout of the Simulink® Verification and Validation™ license when you run the DO-178C/DO-331 checks.

See Also

Check safety-related optimization settings

Check model configuration for optimization settings that can impact safety.

Description

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.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Block reduction optimization is selected. This optimization can remove blocks from generated code, resulting in requirements without associated code and violations for traceability requirements. (See DO-331, Section MB.6.3.4.e—Source code is traceable to low-level requirements.)Clear the Block reductionBlock 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-331, Section MB.6.3.1.e—High-level requirements conform to standards, DO-331, Section MB.6.3.2.e—Low-level requirements conform to standards, and MISRA-C:2004, Rule 12.6.) Select Implement logic signals as boolean data (vs. double)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-331, Section MB.6.3.1.g—Algorithms are accurate, DO-331, Section MB.6.3.2.g—Algorithms are accurate, and MISRA-C:2004, Rule 12.11.)Set Application lifespan (days)Application lifespan (days) on the Optimization pane of the Configuration Parameters dialog box or set the parameter LifeSpan to inf.
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-331, Section MB.6.3.3.b—Software architecture is consistent and MISRA-C:2004, Rule 9.1.)If you have a Embedded Coder® license, and you are using an ERT-based system target file, clear the Remove root level I/O zero initializationRemove 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 every variable. (See DO-331, Section MB.6.3.3.b—Software architecture is consistent and MISRA-C:2004, Rule 9.1.)If you have a Embedded Coder license, and you are using an ERT-based system target file, clear the Remove internal data zero initializationRemove 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 every state variable 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-331, Section MB.6.3.1.g—Algorithms are accurate, DO-331, Section MB.6.3.2.g—Algorithms are accurate, and MISRA-C:2004, Rule 12.11.)If you have a Simulink Coder™ license, select Remove code from floating-point to integer conversions that wraps out-of-range valuesRemove 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-331, Section MB.6.3.1.g—Algorithms are accurate, DO-331, Section MB.6.3.2.g—Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)If you have a Embedded Coder license, and you are using an ERT-based system target file, clear the Remove code that protects against division arithmetic exceptionsRemove 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.
The optimization that uses the specified minimum and maximum values for signals and parameters to optimize the generated code is selected. This might result in requirements without traceable code. (See DO-331 Section MB.6.3.4.e - Source code is traceable to low-level requirements.)If you have a Embedded Coder license, and you are using an ERT-based system target file, clear the Optimize using the specified minimum and maximum values check box on the Optimization pane of the Configuration Parameters dialog box.

Action Results

Clicking Modify Settings configures model optimization settings that can impact safety.

Subchecks depend on the results of the subchecks noted with D in the results table in the Model Advisor window.

See Also

Check safety-related diagnostic settings for solvers

Check model configuration for diagnostic settings that apply to solvers and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to solvers are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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-331, Section MB.6.3.3.e – Software architecture conforms to standards.)Set Algebraic loopAlgebraic 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 so that the 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-331, Section MB.6.3.3.e – Software architecture conforms to standards.)Set Minimize algebraic loopMinimize 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 so that the 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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Block priority violationBlock 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-331, Section MB.6.3.3.e – Software architecture conforms to standards.)Set Unspecified inheritability of sample timesUnspecified inheritability of sample times on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter UnknownTsInhSupMsg 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-331, Section MB.6.3.3.e – Software architecture conforms to standards.)Set Automatic solver parameter selectionAutomatic 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 fix them. (See DO-331, Section MB.6.3.3.b – Software architecture is consistent.)Set State name clashState name clash on the Diagnostics > Solver pane of the Configuration Parameters dialog box or set the parameter StateNameClashWarn to warning.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to solvers and that can impact safety.

See Also

Check safety-related diagnostic settings for sample time

Check model configuration for diagnostic settings that apply to sample time and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to sample times are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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-331, Section MB.6.3.3.e – Software architecture conforms to standards.)Set Source block specifies -1 sample timeSource 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-331, Section MB.6.3.3.e – Software architecture conforms to standards.)Set Discrete used as continuousDiscrete 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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Multitask rate transitionMultitask 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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Multitask conditionally executed subsystemMultitask 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-331, Section MB.6.3.3.e – Software architecture conforms to standards.)Set Enforce sample times specified by Signal Specification blocksEnforce 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.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to sample time and that can impact safety.

See Also

Check safety-related diagnostic settings for signal data

Check model configuration for diagnostic settings that apply to signal data and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to signal data are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Signal resolutionSignal 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-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)Set Division by singular matrixDivision 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 verify the data types of signals. (See DO-331, Section MB.6.3.1.e – High-level requirements conform to standards, and DO-331, Section MB.6.3.2.e – Low-level requirements conform to standards.)Set Underspecified data typesUnderspecified 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-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)Set Detect overflowDetect 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-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)Set Inf or NaN block outputInf 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-331, Section MB.6.3.1.e – High-level requirements conform to standards, and DO-331, Section MB.6.3.2.e – Low-level requirements conform to standards.)Set "rt" prefix for identifiers"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-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)Set Simulation range checkingSimulation range checking on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter SignalRangeChecking to error.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to signal data and that can impact safety.

See Also

Check safety-related diagnostic settings for parameters

Check model configuration for diagnostic settings that apply to parameters and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to parameters are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)Set Detect downcastDetect 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 enough resolution, the parameter value is zero instead of the specified value. This can lead to incorrect operation of generated code. (See DO-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)Set Detect underflowDetect 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 fixed in safety-related applications. (See DO-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rule 21.1.)Set Detect overflowDetect 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-331, Section MB.6.3.1.g – Algorithms are accurate, DO-331, Section MB.6.3.2.g – Algorithms are accurate, and MISRA-C:2004, Rules 10.1, 10.2, 10.3, and 10.4.)Set Detect precision lossDetect 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-331, Section MB.6.3.1.g – Algorithms are accurate and DO-331, Section MB.6.3.2.g – Algorithms are accurate.)Set Detect loss of tunabilityDetect loss of tunability on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter ParameterTunabilityLossMsg to error.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to parameters and that can impact safety.

See Also

Check safety-related diagnostic settings for data used for debugging

Check model configuration for diagnostic settings that apply to data used for debugging and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to debugging are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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 enablingModel Verification block enabling on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter AssertControl to Disable All.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to data used for debugging and that can impact safety.

See Also

  • DO-331, Section MB.6.3.1.e – High-level requirements conform to standards

  • DO-331, Section MB.6.3.2.e – Low-level requirements conform to standards

  • Diagnostics Pane: Data Validity in the Simulink graphical user interface documentation

  • Radio Technical Commission for Aeronautics (RTCA) for information on the DO-178C Software Considerations in Airborne Systems and Equipment Certification and related standards

Check safety-related diagnostic settings for data store memory

Check model configuration for diagnostic settings that apply to data store memory and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to data store memory are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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 writeDetect 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 readDetect 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 writeDetect 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 storeMultitask data store on the Diagnostics > Data Validity pane of the Configuration Parameters dialog box or set the parameter MultiTaskDSMMsg to error.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to data store memory and that can impact safety.

See Also

Check safety-related diagnostic settings for type conversions

Check model configuration for diagnostic settings that apply to type conversions and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to type conversions are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The diagnostic that detects Data Type Conversion blocks used where there is not type conversion 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-331, Section MB.6.3.1.g – Algorithms are accurate and DO-331, Section MB.6.3.2.g – Algorithms are accurate.) Set Unnecessary type conversionsUnnecessary 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-331, Section MB.6.3.1.g – Algorithms are accurate and DO-331, Section MB.6.3.2.g – Algorithms are accurate.)Set Vector/matrix block input conversionVector/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-331, Section MB.6.3.1.g – Algorithms are accurate and DO-331, Section MB.6.3.2.g – 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 conversion32-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.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to type conversions and that can impact safety.

See Also

Check safety-related diagnostic settings for signal connectivity

Check model configuration for diagnostic settings that apply to signal connectivity and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to signal connectivity are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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 mismatchSignal 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 portsUnconnected 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 portsUnconnected 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 lineUnconnected line on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter UnconnectedLineMsg to error.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to signal connectivity and that can impact safety.

See Also

Check safety-related diagnostic settings for bus connectivity

Check model configuration for diagnostic settings that apply to bus connectivity and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to bus connectivity are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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 for compatibility with higher level models that use a model as a reference model. Set Unspecified bus object at root Outport blockUnspecified 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 mismatchElement 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 slreplace_mux utility function to replace all Mux block used as bus creators with a Bus Creator block.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to bus connectivity and that can impact safety.

See Also

Check safety-related diagnostic settings that apply to function-call connectivity

Check model configuration for diagnostic settings that apply to function-call connectivity and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to function-call connectivity are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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 connectionInvalid 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 inputsContext-dependent inputs on the Diagnostics > Connectivity pane of the Configuration Parameters dialog box or set the parameter FcnCallInpInsideContextMsg to Enable all.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to function-call connectivity and that can impact safety.

See Also

Check safety-related diagnostic settings for compatibility

Check model configuration for diagnostic settings that affect compatibility and that might impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to compatibility are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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 neededS-function upgrades needed on the Diagnostics > Compatibility pane of the Configuration Parameters dialog box or set the parameter SFcnCompatibilityMsg to error.

Action Results

Clicking Modify Settings configures model diagnostic settings that affect compatibility and that might impact safety.

See Also

Check safety-related diagnostic settings for model initialization

In the model configuration, check diagnostic settings that affect model initialization and might impact safety.

Description

This check verifies that model diagnostic configuration parameters for initialization are optimally set to generate code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action

In the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane, the Underspecified initialization detection diagnostic is set to Classic, ensuring compatibility with previous releases of Simulink. The Check undefined subsystem initial output diagnostic is cleared. This diagnostic specifies whether Simulink 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.

Do one of the following:

In the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane, the Underspecified initialization detection diagnostic is set to Classic, ensuring compatibility with previous releases of Simulink. The Check preactivation output of execution context diagnostic is cleared. This diagnostic detects potential initial output differences from earlier releases. A conditionally executed subsystem could have an output that is not initialized. If undetected, this condition can produce behavior that is nondeterministic.

Do one of the following:

In the Configuration Parameters dialog box, on the Diagnostics > Data Validity pane, the Underspecified initialization detection diagnostic is set to Classic, ensuring compatibility with previous releases of Simulink. The Check runtime output of execution context diagnostic is cleared. This diagnostic detects potential output differences from earlier releases. 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.

Do one of the following:

Action Results

To configure the diagnostic settings that affect model initialization and might impact safety, click Modify Settings.

Subchecks depend on the results of the subchecks noted with D in the results table in the Model Advisor window.

See Also

Check safety-related diagnostic settings for model referencing

Check model configuration for diagnostic settings that apply to model referencing and that can impact safety.

Description

This check verifies that model diagnostic configuration parameters pertaining to model referencing are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Model block version mismatchModel 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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Port and parameter mismatchPort 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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Model configuration mismatchModel 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 fix the condition. The hidden blocks can result in generated code without traceable requirements. Setting the diagnostic to error forces model developers to fix the referenced models manually. (See DO-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Invalid root Inport/Outport block connectionInvalid 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-331, Section MB.6.3.1.d – High-level requirements are verifiable and DO-331, Section MB.6.3.2.d – Low-level requirements are verifiable.)Set Unsupported data loggingUnsupported 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.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to model referencing and that can impact safety.

See Also

Check safety-related model referencing settings

Check model configuration for model referencing settings that can impact safety.

Description

This check verifies that model configuration parameters for model referencing are set optimally for generating code for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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 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-331, Section MB.6.3.1.b – High-level requirements are accurate and consistent and DO-331, Section MB.6.3.2.b – Low-level requirements are accurate and consistent.) Set Rebuild 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 is set to Never. (See DO-331, Section MB.6.3.1.b – High-level requirements are accurate and consistent and DO-331, Section MB.6.3.2.b – Low-level requirements are accurate and consistent.) Set Never rebuild diagnostic on the Model Referencing pane of the Configuration Parameters dialog box or set the parameter CheckModelReferenceTargetMessage to error.
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-331, Section MB.6.3.3.b – Software architecture is consistent.)Set Pass fixed-size scalar root inputs by value for code generation 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-331, Section MB.6.3.3.b – 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.

Action Results

Clicking Modify Settings configures model referencing settings that can impact safety.

Subchecks depend on the results of the subchecks noted with D in the results table in the Model Advisor window.

See Also

Check safety-related code generation settings

Check model configuration for code generation settings that can impact safety.

Description

This check verifies that model configuration parameters for code generation are set optimally for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The option to include comments in the generated code is cleared. Comments provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Select Include commentsInclude comments on the Code Generation > 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 provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Select Simulink block / Stateflow object commentsSimulink block / Stateflow object comments on the Code Generation > 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 provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Select Show eliminated blocksShow eliminated blocks on the Code Generation > 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 provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Select Verbose comments for SimulinkGlobal storage classVerbose comments for SimulinkGlobal storage class on the Code Generation > 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 provide good traceability between the code and the model. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Select Requirements in block commentsRequirements in block comments on the Code Generation > 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-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Clear Support: non-finite numbersSupport: non-finite numbers on the Code Generation > 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-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Clear Support: absolute timeSupport: absolute time on the Code Generation > 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-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Clear Support: continuous timeSupport: continuous time on the Code Generation > 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-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Clear Support: non-inlined S-functionsSupport: non-inlined S-functions on the Code Generation > 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 pre-R2012a GRT target is selected. This option is inappropriate for real-time safety-related systems. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Clear Classic call interfaceClassic call interface on the Code Generation > 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-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Select Single output/update functionSingle output/update function on the Code Generation > 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 unsuitable for real-time safety-related systems. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Clear Terminate function requiredTerminate function required on the Code Generation > 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 Simulink Coder product generates extra code that might not be reachable for testing. (See DO-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Select Suppress error status in real-time model data structureSuppress error status in real-time model data structure on the Code Generation > 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-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer and DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer.)Clear MAT-file loggingMAT-file logging on the Code Generation > 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-331, Section MB.6.3.1.c – High-level requirements are compatible with target computer, DO-331, Section MB.6.3.2.c – Low-level requirements are compatible with target computer, and MISRA-C:2004, Rule 12.1.)Set Parenthesis levelParenthesis level on the Code Generation > 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-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Select Preserve operand order in expressionPreserve operand order in expression on the Code Generation > 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-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Select Preserve condition expression in if statementPreserve condition expression in if statement on the Code Generation > Code pane of the Configuration Parameters dialog box or set the parameter PreserveIfCondition to on.
The option that specifies whether to generate preprocessor conditional directives is set to generate code for nonactive variants. This might result in generating code that does not trace to the active variant of a variant model block or a variant subsystem. (See DO-331 Section MB.6.3.4.e — Source code is traceable to low-level requirements.)Set Generate preprocessor conditionals on the Code Generation > Interface pane of the Configuration Parameters dialog box to Disable All.
The minimum number of characters specified for generating name mangling strings is less than four. You can use this option to minimize the likelihood that parameter and signal names will change during code generation when the model changes. Use of this option assists with minimizing code differences between file versions, decreasing the effort to perform code reviews. (See DO-331, Section MB.6.3.4.e – Source code is traceable to low-level requirements.)Set Minimum mangle lengthMinimum mangle length on the Code Generation > Symbols pane of the Configuration Parameters dialog box or the parameter MangleLength to a value of 4 or greater.

Action Results

Clicking Modify Settings configures model code generation settings that can impact safety.

Subchecks depend on the results of the subchecks noted with D in the results table in the Model Advisor window.

See Also

Check safety-related diagnostic settings for saving

Check model configuration for diagnostic settings that apply to saving model files

Description

This check verifies that model configuration parameters are set optimally for saving a model for a safety-related application.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended 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.Set Block diagram contains disabled library linksBlock 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.Set Block diagram contains parameterized library linksBlock diagram contains parameterized library links on the Diagnostics > Saving> pane of the Configuration Parameters dialog box or set the parameter SaveWithParameterizedLinkMsg to error.

Action Results

Clicking Modify Settings configures model diagnostic settings that apply to saving a model file.

See Also

Check for blocks that do not link to requirements

Check whether Simulink blocks and Stateflow® objects link to a requirements document.

Description

This check verifies whether Simulink blocks and Stateflow objects link to a document containing engineering requirements for traceability.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Blocks do not link to a requirements document.Link to requirements document. See Link to Requirements Document Using Selection-Based Linking.

Capabilities and Limitations

  • You can run this check on your library models.

  • When you run this check, the Model Advisor does not follow library links or look under masks.

Tip

Run this check from the top model or subsystem that you want to check.

See Also

  • DO-331, Section MB.6.3.1.f - High-level requirements trace to system requirements

  • DO-331, Section MB.6.3.2.f - Low-level requirements trace to high-level requirements

  • Requirements Traceability

Check usage of Math blocks

Check whether math operators require nonfinite number support.

Description

This check verifies that Math Function blocks do not use math operations that need nonfinite number support with real-time embedded targets.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Math Function blocks using log (natural logarithm), log10 (base 10 logarithm), and rem (Remainder) operators that require nonfinite number support.

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 than 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.

Capabilities and Limitations

You can run this check on your library models.

Tips

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.

See Also

  • DO-331, Sections MB.6.3.1.g and MB.6.3.2.g - Algorithms are accurate

  • MISRA-C:2004, Rule 21.1

  • Math Function block in the Simulink documentation

Check state machine type of Stateflow charts

Identify whether Stateflow charts are all Mealy or all Moore charts.

Description

Compares the state machine type of all Stateflow charts to the type that you specify in the input parameters.

Available with Simulink Verification and Validation.

Input Parameters

Common

Check whether charts use the same state machine type, and are all Mealy or all Moore charts.

Mealy

Check whether all charts are Mealy charts.

Moore

Check whether all charts are Moore charts.

Results and Recommended Actions

ConditionRecommended Action
The input parameter is set to Common and charts in the model use either of the following:
  • Classic state machine types.

  • Multiple state machine types.

For each chart, in the Chart Properties dialog box, specify State Machine Type to either Mealy or Moore. Use the same state machine type for all charts in the model.
The input parameter is set to Mealy and charts in the model use other state machine types.For each chart, in the Chart Properties dialog box, specify State Machine Type to Mealy.
The input parameter is set to Moore and charts in the model use other state machine types.For each chart, in the Chart Properties dialog box, specify State Machine Type to Moore.

Capabilities and Limitations

You can run this check on your library models.

See Also

  • DO-331, Section MB.6.3.1.b - High-level requirements are accurate and consistent

  • DO-331, Section MB.6.3.1.e - High-level requirements conform to standards

  • DO-331, Section MB.6.3.2.b - Low-level requirements are accurate and consistent

  • DO-331, Section MB.6.3.2.e - Low-level requirements conform to standards

  • DO-331, Section MB.6.3.3.b - Software architecture is consistent

  • DO-331, Section MB.6.3.3.e - Software architecture conform to standards

  • hisf_0001: Mealy and Moore semantics

  • Overview of Mealy and Moore Machines

  • Chart Properties

  • Chart Architecture

Check Stateflow charts for ordering of states and transitions

Identify Stateflow charts that have User specified state/transition execution order cleared.

Description

Identify Stateflow charts that have User specified state/transition execution order cleared, and therefore do not use explicit ordering of parallel states and transitions.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Stateflow charts have User specified state/transition execution order cleared. For the specified charts, in the Chart Properties dialog box, select User specified state/transition execution order.

Capabilities and Limitations

You can run this check on your library models.

Action Results

Clicking Modify selects User specified state/transition execution order for the specified charts.

See Also

Check Stateflow debugging options

Identify whether Stateflow debugging options are cleared.

Description

Identify whether the following debugging options are cleared, which might lead to unreachable code and indeterminate execution time:

  • Enable debugging/animation

  • Enable overflow detection (with debugging)

  • Transition Conflict

  • Data Range

  • Detect Cycles

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Any of the following debugging options are cleared:
  • Enable debugging/animation

  • Enable overflow detection (with debugging)

  • Transition Conflict

  • Data Range

  • Detect Cycles

Select the debugging options.

In the Configuration Parameters dialog box, select:

  • Simulation Target > General > Enable debugging/animation

  • Simulation Target > General > Enable overflow detection (with debugging)

In the Stateflow Debugging dialog box, select:

  • Transition Conflict

  • Data Range

  • Detect Cycles

Action Results

Clicking Modify selects the specified debugging options.

See Also

  • DO-331, Section MB.6.3.1.b - High-level requirements are accurate and consistent

  • DO-331, Section MB.6.3.1.e - High-level requirements conform to standards

  • DO-331, Section MB.6.3.2.b - Low-level requirements are accurate and consistent

  • DO-331, Section MB.6.3.2.e - Low-level requirements conform to standards

  • hisf_0011: Stateflow debugging settings

  • Chart Properties

  • Chart Architecture

Check usage of lookup table blocks

Check for lookup table blocks that do not generate out-of-range checking code.

Description

This check verifies that the following blocks generate code to protect against inputs that fall outside the range of valid breakpoint values:

This check also verifies that Interpolation Using Prelookup blocks generate code to protect against inputs that fall outside the range of valid index values.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action

The lookup table block does not generate out-of-range checking code.

Change the setting on the block dialog box so that out-of-range checking code is generated.

  • For the 1-D Lookup Table, 2-D Lookup Table, n-D Lookup Table, and Prelookup blocks, clear the check box for Remove protection against out-of-range input in generated code.

  • For the Interpolation Using Prelookup block, clear the check box for Remove protection against out-of-range index in generated code.

Action Results

Clicking Modify verifies that lookup table blocks are set to generate out-of-range checking code.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check MATLAB Code Analyzer messages

Check MATLAB Functions for %#codegen directive, MATLAB Code Analyzer messages, and justification message IDs.

Description

Verifies %#codegen directive, MATLAB Code Analyzer messages, and justification message IDs for:

  • MATLAB code in MATLAB Function blocks

  • MATLAB functions defined in Stateflow charts

  • Called MATLAB functions

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
For MATLAB code in MATLAB Function blocks, either of the following:
  • Code lines are not justified with a %#ok comment.

  • Codes lines justified with %#ok do not specify a message id.

  • Implement MATLAB Code Analyzer recommendations.

  • Justify not following MATLAB Code Analyzer recommendations with a %#ok comment.

  • Specify justified code lines with a message id. For example, %#ok<NOPRT>.

For MATLAB functions defined in Stateflow charts, either of the following:
  • Code lines are not justified with a %#ok comment.

  • Codes lines justified with %#ok do not specify a message id.

  • Implement MATLAB Code Analyzer recommendations.

  • Justify not following MATLAB Code Analyzer recommendations with a %#ok comment.

  • Specify justified code lines with a message id. For example, %#ok<NOPRT>.

For called MATLAB functions:
  • Code does not have the %#codegen directive.

  • Code lines are not justified with a %#ok comment.

  • Codes lines justified with %#ok do not specify a message id.

  • Insert %#codegen directive in the MATLAB code.

  • Implement MATLAB Code Analyzer recommendations.

  • Justify not following MATLAB Code Analyzer recommendations with a %#ok comment.

  • Specify justified code lines with a message id. For example, %#ok<NOPRT>.

See Also

Check MATLAB code for global variables

Check for global variables in MATLAB code.

Description

Verifies that global variables are not used in any of the following:

  • MATLAB code in MATLAB Function blocks

  • MATLAB functions defined in Stateflow charts

  • Called MATLAB functions

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Global variables are used in one or more of the following:
  • MATLAB code in MATLAB Function blocks

  • MATLAB functions defined in Stateflow charts

  • Called MATLAB functions

Replace global variables with signal lines, function arguments, or persistent data.

See Also

Check for inconsistent vector indexing methods

Identify blocks with inconsistent indexing method.

Description

Using inconsistent block indexing methods can result in modeling errors. You should use a consistent vector indexing method for all blocks. This check identifies blocks with inconsistent indexing methods. The indexing methods are zero-based, one-based or user-specified.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action

The model or subsystem contains blocks with inconsistent indexing methods. The indexing methods are zero-based, one-based or user-specified.

Modify the model to use a single consistent indexing method.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check for MATLAB Function block interfaces with inherited properties

Identify MATLAB Function blocks that have inputs, outputs or parameters with inherited complexity or data type properties.

Description

The check identifies MATLAB Function blocks with inherited complexity or data type properties. A results table provides links to MATLAB Function blocks that do not pass the check, along with conditions triggering the warning.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
MATLAB Function blocks have inherited interfaces.

Explicitly define complexity and data type properties for inports, outports, and parameters of MATLAB Function block identified in the results.

If applicable, using the MATLAB Function Block Editor, make the following modifications in the Ports and Data Manager:

  • Change Complexity from Inherited to On or Off.

  • Change Type from Inherit: Same as Simulink to an explicit type.

In the results table, Compiled Value provides suggestions for the actual values after the model compiles. If a MATLAB Function block is defined within a library, explicitly define the interface in the library rather than in the referencing model. If your model has multiple instances of MATLAB Function blocks defined in a library block, and the instances have different interface properties, consider using multiple library blocks.

See Also

Check MATLAB Function block metrics

Display complexity and code metrics for MATLAB Function blocks and external MATLAB functions. Report metric violations.

Description

This check provides complexity and code metrics for MATLAB Function blocks and external MATLAB functions. The check additionally reports metric violations.

A results table provides links to MATLAB Function blocks and external MATLAB functions that violate the complexity input parameters.

Available with Simulink Verification and Validation.

Input Parameters

Maximum effective lines of code per function

Provide the maximum effective lines of code per function. Effective lines do not include empty lines, comment lines, or lines with a function end keyword.

Minimum density of comments

Provide minimum density of comments. Density is ratio of comment lines to total lines of code.

Maximum cyclomatic complexity per function

Provide maximum cyclomatic complexity per function. Cyclomatic complexity is the number of linearly independent paths through the source code.

Results and Recommended Actions

ConditionRecommended Action
MATLAB Function blocks or external MATLAB functions violate the complexity input parameters.For the MATLAB Function block or external MATLAB function:
  • If effective lines of code is too high, further divide the MATLAB function.

  • If comment density is too low, add comment lines.

  • If cyclomatic complexity per function is too high, further divide the MATLAB function.

See Also

Check for blocks not recommended for C/C++ production code deployment

Identify blocks not supported by code generation or not recommended for C/C++ production code deployment.

Description

This check partially identifies model constructs that are not recommended for C/C++ production code generation as identified in the Simulink Block SupportSimulink Block Support tables for Simulink Coder and Embedded Coder. If you are using blocks with support notes for code generation, review the information and follow the given advice.

Available with Simulink Verification and Validation and Embedded Coder.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains blocks that should not be used for production code deployment.Consider replacing the blocks listed in the results. Click an element from the list of questionable items to locate condition.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check Stateflow charts for uniquely defined data objects

Identify Stateflow charts that include data objects that are not uniquely defined.

Description

This check searches your model for local data in Stateflow charts that is not uniquely defined.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The Stateflow chart contains a data object identifier defined in two or more scopes.

For the identified chart, do one of the following:

  • Create a unique data object identifier within each of the scopes.

  • Create a unique data object identifier within the chart, at the parent level.

Capabilities and Limitations

You can run this check on your library models.

See Also

Check usage of Math Operations blocks

Identify usage of Math Operation blocks that might impact safety.

Description

This check inspects the usage of the following blocks:

  • Abs

  • Gain

  • Math Function

    • Natural logarithm

    • Common (base 10) logarithm

    • Remainder after division

    • Reciprocal

  • Assignment

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains an Absolute Value block that is operating on one of the following:
  • A boolean or an unsigned input data type. This condition results in unreachable simulation pathways through the model and might result in unreachable code

  • A signed integer value with the Saturate on integer overflow check box not selected. For signed data types, the absolute value of the most negative value is problematic because it is not representable by the data type. This condition results in an overflow in the generated code.

If the identified Absolute Value block is operating on a boolean or unsigned data type, do one of the following:

  • Change the input of the Absolute Value block to a signed input type.

  • Remove the Absolute Value block from the model.

If the identified Absolute Value block is operating on a signed data type, in the Block Parameters > Signal Attributes dialog box, select Saturate on integer overflow.

The model or subsystem contains Gain blocks with a of value 1.If you are using Gain blocks as buffers, consider replacing them with Signal Conversion blocks.
The model or subsystem contains Math Function - Natural logarithm (log) blocks that might result in non-finite output signals. Non-finite signals are not supported in real-time embedded systems.

When using the Math Function block with a log function, protect the input to the block from being less than or equal to zero. Otherwise, the output can produce a NaN or -Inf and result in a run-time error in the generated code.

The model or subsystem contains Math Function - Common (base 10)(base 10 logarithm) blocks that might result in non-finite output signals. Non-finite signals are not supported in real-time embedded systems.

When using the Math Function block with a log10 function, protect the input to the block from being less than or equal to zero. Otherwise, the output can produce a NaN or -Inf and result in a run-time error in the generated code.

The model or subsystem contains Math Function - Remainder after division(rem) blocks that might result in non-finite output signals. Non-finite signals are not supported in real-time embedded systems.

When using the Math Function block with a rem function, protect the second input to the block from being equal to zero. Otherwise the output can produce a Inf or -Inf and result in a run-time error in the generated code.

The model or subsystem contains Math Function - Reciprocal (reciprocal) blocks that might result in non-finite output signals. Non-finite signals are not supported in real-time embedded systems.

When using the Math Function block with a reciprocal function, protect the input to the block from being equal to zero. Otherwise the output can produce a Inf or -Inf and result in a run-time error in the generated code.

The model or subsystem might contain Assignment blocks with incomplete array initialization that do not have block parameter Action if any output element is not assigned set to Error.

When using the Assignment block with incompleted array initialization, set block parameter Action if any output element is not assigned to Error.

See Also

Check usage of Signal Routing blocks

Identify usage of Signal Routing blocks that might impact safety.

Description

This check identifies model or subsystem Switch blocks that might generate code with inequality operations (~=) in expressions that contain a floating-point variable or constant.

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains a Switch block that might generate code with inequality operations (~=) in expressions where at least one side of the expression contains a floating-point variable or constant. The Switch block might cause floating-point inequality comparisons in the generated code.

For the identified block, do one of the following:

  • For the control input block, change the Data type parameter setting.

  • Change the Switch block Criteria for passing first input parameter setting. This might change the algorithm.

See Also

  • DO-331, Sections MB.6.3.1.g and MB.6.3.2.g - Algorithms are accurate

  • MISRA-C:2004, Rule 13.3

Check usage of Logic and Bit Operations blocks

Identify usage of Logical Operator and Bit Operations blocks that might impact safety.

Description

This check inspects the usage of:

  • Blocks that compute relational operators, including Relational Operator, Compare To Constant, Compare To Zero, and Detect Change blocks

  • Logical Operator blocks

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains a block computing a relational operator that is operating on different data types. The condition can lead to unpredictable results in the generated code. On the Block Parameters > Signal Attributes pane, set the Output data type to boolean for the specified blocks.
The model or subsystem contains a block computing a relational operator that uses the == or ~= operator to compare floating-point signals. The use of these operators on floating-point signals is unreliable and unpredictable because of floating-point precision issues. These operators can lead to unpredictable results in the generated code.

For the identified block, do one of the following:

  • Change the signal data type.

  • Rework the model to eliminate using == or ~= operators on floating-point signals.

The model or subsystem contains a Logical Operator block that has inputs or outputs that are not Boolean inputs or outputs. The block might result in floating-point equality or inequality comparisons in the generated code.
  • Modify the Logical Operator block so that all inputs and outputs are Boolean. On the Block Parameters > Signal Attributes pane, consider selecting Require all inputs to have the same data type and setting Output data type to boolean.

  • In the Configuration Parameters dialog box, on the Optimization pane, consider selecting the Implement logic signals as boolean data (vs. double).

See Also

Check usage of Ports and Subsystems blocks

Identify usage of Ports and Subsystems blocks that might impact safety.

Description

This check inspects the usage of:

  • For Iterator blocks

  • While Iterator blocks

  • If blocks

  • Switch Case blocks

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
The model or subsystem contains a For Iterator block that has variable iterations. This condition can lead to unpredictable execution times or infinite loops in the generated code.For the identified For Iterator blocks, do one of the following:
  • Set the Iteration limit source parameter to internal.

  • If the Iteration limit source parameter must be external, use a Constant, Probe, or Width block as the source.

  • Clear the Set next i (iteration variable) externally check box.

  • Consider selecting the Show iteration variable check box and observe the iteration value during simulation.

The model or subsystem contains a While Iterator block that has unlimited iterations. This condition can lead to infinite loops in the generated code. For the identified While Iterator blocks:
  • Set the Maximum number of iterations (-1 for unlimited) parameter to a positive integer value.

  • Consider selecting the Show iteration number port check box and observe the iteration value during simulation.

The model or subsystem contains an If block with an If expression or Elseif expressions that might cause floating-point equality or inequality comparisons in generated code.Modify the expressions in the If block to avoid floating-point equality or inequality comparisons in generated code.
The model or subsystem contains an If block using Elseif expressions without an Else condition.In the If block Block Parameters dialog box, select Show else condition. Connect the resulting Else output port to an If Action Subsystem block.
The model or subsystem contains an If block with output ports that do not connect to If Action Subsystem blocks.Verify that output ports of the If block connect to If Action Subsystem blocks.
The model or subsystem contains an Switch Case block without a default case.In the Switch Case block Block Parameters dialog box, select Show default case. Connect the resulting default output port to a Switch Case Action Subsystem block.
The model or subsystem contains a Switch Case block with an output port that does not connect to a Switch Case Action Subsystem block.Verify that output ports of the Switch Case blocks connect to Switch Case Action Subsystem blocks.

See Also

Display model version information

Display model version information in your report.

Description

This check displays the following information for the current model:

  • Version number

  • Author

  • Date

  • Model checksum

Available with Simulink Verification and Validation.

Results and Recommended Actions

ConditionRecommended Action
Could not retrieve model version and checksum information. This summary is provided for your information. No action is required.

See Also

Was this topic helpful?