When we ship blocks which are implemented as masked subsystems, under some circumstances we will explicitly disable coverage for certain "sub-blocks" under the mask. This might be done for various reasons, such as to avoid unsatisfiable objectives, ignore intermediate operations not pertinent in a customer's context, or just generally so that the coverage reported for the block better matches the conceptual behavior of the block.
In this case we have disabled coverage for the Relational Operator blocks under the mask of the Saturation Dynamic block. (You can confirm this by checking the 'DisableCoverage' parameter on each block)
Here, the Relational Operators feed directly into Switches. As such, condition coverage for the Relational Operator is no more informative than decision coverage for the Switch.
Furthermore, this makes coverage for the Saturation Dynamic block more consistent with coverage for the standard Saturation block. Both report two decision objectives -- one for exercising the upper boundary and another for exercising the lower boundary.
Best Answer