Analyze Models with Counters and Timers

If your model contains counter or timer blocks, Simulink® Design Verifier™ analysis searches through sequences of states to find input values that satisfy specific objectives. The analysis prioritizes configurations that can be reached in fewer time steps. Long timers and counters lead to a vast number of states that the analysis must cover, especially when they involve time delays or countdowns. The presence of timers and counters in your model can significantly impact the complexity and duration of model analysis using Simulink Design Verifier. Some challenges of analyzing models with long counters and timers include:

  • State explosion, which occurs when long timers or counters vastly increase the number of states that the analysis must cover

  • Delayed response, such as filtering or averaging, which extends the number of timer steps required and leads to longer test cases

  • Enabling the Run exhaustive analysis parameter, causes the dead logic detection analysis to take a considerable amount of time when your model has timers within a Stateflow® chart

Modeling Patterns and Their Impact on Analysis

Different modeling patterns can affect the Simulink Design Verifier in different ways. For example, in control systems, a pattern such as debouncing are used to manage response to specific conditions. The controller waits for a specified period until a certain condition arise.

A counter with an attached scope block to the output of the delay block shows how the value increases until it becomes ten at which point you satisfy the decision objective. Beginning from the Initial State, when the counter enters the timer activation state, it pauses in the timer progress region for a specified duration before executing a new action.

Timer state trajectory during simulation.

Simulink Design Verifier navigates through a sequence of states to identify input values that lead the analysis to a state that satisfies a test objective. Timer patterns complicate this process by creating extended sequences of states in timer progress regions. As a result, it becomes challenging for the analysis to achieve the test objectives that occur after the timer progress region. Detecting such patterns is complicated by the modeling styles that you use during the analysis.

Modeling Pattern and DescriptionImpact on Test Objective
Counters: Track the number of occurrences of an event or number of times an operation is performed​. For more information on counters, see Counter Free-Running.

Decision objective of relational block – output is true. This objective is satisfied only after 10 steps of simulation of the model.

Counter block for decision objective.

Integrator: Accumulate values over time. The accumulated value is often saturated to bound values within thresholds​. For more information on integrators, see Integrator.

Decision objective for saturation limits. To satisfy the decision objective for (integration result > Upper saturation limit) true objective of the integrator block, steps may be needed until the values of the input signal have accumulated up to the limit.​

Integrator block with saturation limits.

Rising Edge or Falling Edge: Detect transitions from a low state to a high state. Time duration impacts the rising or falling edge. For more information, see Detect Change.

Checking objectives within the subsystem. The rising edge trigger requires zero crossing of the input to the trigger. As a result, a slow changing input may require higher number of steps for zero crossing.​

Rising edge.

Counters in MATLAB® functions: Use counters in MATLAB functions to implement using simple variables that increment within loops or conditional statements.

Decision for branch u> 0. This branch can be checked only when counter > 10. This requires MATLAB function to run for at least 10 steps. ​

function y = fcn(u)
persistent counter;

 if isempty (counter)
     counter = 0;
 end

 counter = counter + 1;
 y = 0;
 if (counter > 10)
     counter = 0;
     if (u > 0)
         y = 1;
     end 
 end
end

Timer patterns in Stateflow®: Wait for a specified amount of time before executing a function. For more information, see Reduce Transient Signals by Using Debouncing Logic (Stateflow).

Decision objective to reach State S5. This is guarded by temporal condition of [after(0.8,sec)] which is true only after the given duration. The actual number of duration steps depend on sample time of the model.​

Timer patterns in Stateflow.

​

Optimize Simulink Design Verifier Analysis of Models Using Timers and Counters

You can use workarounds to manage the complexity that arise by using timers and counters in your model for Simulink Design Verifier analysis. Basic workarounds include:

ScenariosRecommended ActionAnalysis Behavior

Perform the analysis for the first time to obtain coverage.

Not applicable

Analysis uses internal heuristics to automatically detect and pass the timer progress region. For more information, see Perform Analysis on Large Models.

Detect undesired behaviors of the model that are reachable after timer progress regions.

  • Use test case generated for the model with the small delay to the original model. Select delay values so that they are satisfied progressively.​

  • Choose high frequency cutoffs for filters and fewer samples to average to minimize filtering delays.

Analysis can pass through the timer progress region quickly and analyze the design for states beyond that for checking undesired behaviors.​

​

Note

A system with a logical error when a time delay is set to 2000 steps usually demonstrates the same error if the time delay is changed to 2 seconds.

Target the objectives impacted by timers.

Set initial counter and timer values as parameters that Simulink Design Verifier analysis can adjust, resulting in shorter test cases.

Analysis selects initial values that allow shorter test cases to exceed the thresholds. For more information, see Extend Existing Test Cases After Applying Parameter Configurations​.

Use these workarounds when you have undecided objectives impacted by timers and you want to rerun the analysis.

Recommended ActionsAnalysis Behavior

Execute sldvtimer(model) to check whether the timer optimization is possible on the model. If yes, execute sldvtimer(1) at the MATLAB and rerun the analysis.

Analysis uses additional timer detection heuristics for timer detection. For more information, see sldvtimer.

Use existing test cases that exhaust timers or counters and extend them to form a comprehensive test suite.

Analysis uses the existing test input as a starting point. It directly jumps to the state sequence reachable after you simulate this input. ​For more information, see Extend an Existing Test Suite.

Add custom test objectives as an intermediate step to achieve unresolved objectives.

Once these custom objectives are satisfied, the analysis reaches a state from which you can achieve the unresolved objectives.​

  • Set timers and counters threshold values in terms of number of simulation steps needed.​

  • Use the int data type for variables and constants defined in the model.

Analysis selects initial values that allow shorter test cases to exceed the thresholds. For more information, see Extend Existing Test Cases After Applying Parameter Configurations​.

See Also

| | |

Topics