An introduction to Modified Condition/Decision Coverage (MC/DC)
Modified Condition/Decision Coverage (MC/DC) is a method of ensuring adequate testing for safety-critical software. At its core lies the idea that if a choice can be made, all the possible factors (conditions) which contribute to that choice (decision) must be tested.
For instance, if I want to decide what to wear one day, my choice of whether to put on a jacket might be broken down into the following decision:
Jacket = Cold ∨ Raining ∨ Windy
NB: I've chosen to use first-order logical operators to represent these expressions because it avoids the issue of shortcutting logical operators, such as C-style && and ||.
For MC/DC to be complete for this decision, I will need to show that each of these conditions can affect the outcome, and this is accomplished by finding a specific pair of states which show this effect. The pair must be identical except for the value of that one condition. For example, if the decision is taken on two days, Monday and Tuesday:
Day Temperature Precipitation Wind Speed Monday 20°C 0mm 2kph Tuesday 22°C 0mm 25kph
One might consider them to represent the expressions:
Monday = ¬Cold ∧ ¬Windy ∧ ¬Raining Tuesday = ¬Cold ∧ Windy ∧ ¬Raining
This pair would be sufficient to show that if only the state of the Windy condition changes, the decision to wear a jacket also changes, since I would choose to wear a jacket on Tuesday, but not on Monday.
So, for the whole decision, I will need three pairs of tests, which means a bare minimum of four distinct condition states. The pairs for this example might be:
Cold: ¬Cold ∧ ¬Windy ∧ ¬Raining Cold ∧ ¬Windy ∧ ¬Raining Windy: ¬Cold ∧ ¬Windy ∧ ¬Raining ¬Cold ∧ Windy ∧ ¬Raining Raining: ¬Cold ∧ ¬Windy ∧ ¬Raining ¬Cold ∧ ¬Windy ∧ Raining
As you can see, the first state in each pair is the same. Any pair would do, so long as only one condition changes between the states. Find out more about MC/DC on our discovery page.
White papers & webinars
Want to learn about common challenges and solutions in critical software verification? Our white papers and webinars may be just the thing:
- Multicore Timing Analysis for DO-178C
- Eight top code coverage questions in embedded avionics systems
- Seven Roadblocks to 100% structural coverage (and how to avoid them)
- Automating WCET Analysis for DO-178B & DO-178C
- Three steps to avoid software obsolescence in avionic systems
- CodeTEST® Replacement with RVS
- Multicore Timing Analysis for DO178 Projects Webinar
- Multicore for ISO 26262 Webinar