What Is MCDC? - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 6:03
Loaded: 2.73%
Stream Type LIVE
Remaining Time 6:03
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 6:03

    What Is MCDC?

    Engineers who test safety-critical software are often confronted with a test coverage metric called “MCDC.” You can use Simulink Coverage™ to measure MCDC.

    You will learn:

    1. What is MCDC?
    2. Why is MCDC used?
    3. What can I do if my requirements-based test cases do not achieve full MCDC?

    Published: 8 May 2022

    Engineers who test safety critical software are often confronted with a test coverage metric called MCDC. In this video, you will learn what is MCDC, why is MCDC used, and what can I do if my requirements based test cases do not achieve full MCDC. First, what is MCDC? MCDC, which stands for Modified Condition Decision Coverage, is a structural coverage metric.

    Structural coverage analysis measures how much of your design has been tested. Two common forms of structural coverage are decision and condition coverage. MCDC extends decision and condition coverage by requiring that each condition should independently affect the decision outcome.

    In other words, MCDC shows how a given input independently affects the output of a logical expression. Here is a simple example to explain the concept. This model has an or gate, and gate, and a switch with three Boolean inputs A, B, and C and integer output Y. To achieve full MCDC, we need to develop test factors that ensure that each of the inputs independently affects the output. We can write the test case in a test sequence block.

    The test sequence initializes all three inputs to false, which sets output Y to negative 1. In step one, let's hold inputs A and B to false and set input C to true. Output Y will remain negative 1.

    In step two, let's set input B to true. This will set output Y to one and will demonstrate how input B independently affects the output. In step three, let's demonstrate how inputs C independently affects output Y. We can do this by setting input C to false. This will set output Y to negative 1.

    The only remaining step is to demonstrate how input a independently affects output Y. To do this, let's set input A to true and input B to false. This will set output Y to 1. When combined with step one, this demonstrates how input A independently affects the output.

    This simple example shows how to achieve full MCDC by holding certain inputs constant to show how a given input independently affects the output of a logical expression. Why is MCDC used? Standards such as DO 1.78 and ISO 26262 require full MCDC for software developed to the highest criticality level. When you achieve full MCDC, you will have tested each condition in your design at a time that it mattered when it affects the output of an expression. This can improve the effectiveness and efficiency of your tests.

    What can I do if my requirements-based test cases don't achieve full MCDC. For each uncovered objective, you should ask, why does this condition not affect the outcome? First, look at the collective coverage to see if there are any errors in your design. This might take the form of dead logic. How would these errors affect how the uncovered objective affects the output of the expression?

    Second, look for opportunities to augment your existing requirements-based test cases. Make sure to update the expected results if necessary, and be sure the traceability to requirements is valid. Third, the uncovered objective may be the result of a derived requirement. A derived requirement, in this case, is a part of your design, which is not the direct result of a higher level requirement. A best practice is to document and write test cases for these derived requirements.

    Finally, if you are sure none of the above applies, you can justify the missing coverage after analyzing its impact on the design. You can then filter out specific coverage objectives during testing. In general, you can consider justifying missing coverage for logic that you did not intend to exercise in your current testing context. A common example of this is dead logic due to defensive coding practices. It is important that the justification rationale be clear in case the design is modified in the future or if the testing context changes.

    You can use Simulink Design Verifier to check for dead logic before simulating your models. The tool can show you which MCDC objectives are unreachable and can automatically create a filter for unreachable or dead objectives. You can also use Simulink Design Verifier to automatically generate test vectors. You can simulate these test vectors to understand how to achieve full MCDC. To learn more, visit the semi-link coverage product page on mathworks.com.

    View more related videos