On improving efficiency of model checking through systematically ...
On improving efficiency of model checking through systematically ...
On improving efficiency of model checking through systematically ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
the reachable state space remains unchanged. When Uppaal deals with such<br />
infinite system, it will search on all possibilities for Integer variable x in the<br />
default range <strong>of</strong> Integer numbers, i.e [−32768, 32767]. This method leads to<br />
the state space explosion in the verification <strong>of</strong> the class <strong>of</strong> infinite systems<br />
that involve unbounded Integers.<br />
Since we could not touch the underlying algorithm <strong>of</strong> any <strong>model</strong> checkers,<br />
we had to find some ways to solve the above problem at the <strong>model</strong> level.<br />
We tried to put a restriction on the number <strong>of</strong> iterations around the good<br />
location a system can take. This mechanism should be done automatically.<br />
There are two ways we can restrict the number <strong>of</strong> iterations in a <strong>model</strong>:<br />
1. Restrict the number <strong>of</strong> iterations directly using a counter and limitation<br />
as we have done to measure the memory usage after every<br />
iteration. We implemented that restriction for the <strong>model</strong> containing<br />
one good location by modifying the transformation tool so that it can<br />
generate a <strong>model</strong> as presented in Figure 5.1.<br />
2. Restrict the length <strong>of</strong> sequence <strong>of</strong> input values generated by the input<br />
graph. It would be more natural if we constrain the number <strong>of</strong> times<br />
a system goes <strong>through</strong> a good location this way. However, we did not<br />
implement this option for the following reason:<br />
Sometimes the system can be blocked on the good location(s) by input<br />
values from the external environment. Consider Figure 5.5.<br />
input <br />
¬cond<br />
input !<br />
input <br />
l 1 l 2<br />
cond<br />
l 0<br />
System graph<br />
Input graph<br />
Figure 5.5: An illustration <strong>of</strong> blocking due to input values<br />
In Figure 5.5, it is possible that after getting input values for the first<br />
time in location l 1 , the guard cond is not enabled yet and thus the<br />
transition (l 1 ,l 2 ) cannot be taken. We modify the <strong>model</strong> so that the<br />
system will try to get input values for several times until the guard on<br />
transition (l 1 ,l 2 ) is enabled. In the case where there is no such input<br />
value that (l 1 ,l 2 ) can be taken, there must be something wrong in the<br />
<strong>model</strong>.<br />
Remember that the execution <strong>of</strong> two graphs are alternative, meaning<br />
that the schedule for two graphs is (system,input,system,input...).<br />
54
Change language