This issue tracker is closed. Please visit UPPAAL issue tracker at Github instead.

Bug 533 - The verification of a "sup" property based on a clock value does not terminate
Summary: The verification of a "sup" property based on a clock value does not terminate
Status: NEW
Alias: None
Product: UPPAAL
Classification: Unclassified
Component: Engine (show other bugs)
Version: 4.1.3
Hardware: Macintosh Mac OS
: P2 normal
Assignee: Alexandre David
Depends on:
Reported: 2012-01-19 12:23 CET by Hang Yin
Modified: 2012-01-19 12:26 CET (History)
0 users

See Also:

The xml and q files of the model (2.87 KB, application/zip)
2012-01-19 12:26 CET, Hang Yin

Note You need to log in before you can comment on or make changes to this bug.
Description Hang Yin 2012-01-19 12:23:51 CET
By using traditional UPPAAL modeling and verifying techniques (the second property in the property list), it can be found that the maximal clock value in state "Waiting" of "MSTS" is 12. But the property "sup{MSTS.Waiting}: MSTS.x" does not terminate. It is expected that the same value 12 should be obtained from its verification result. The "sup" property works fine in some other states of other templates, but the reason why it does not terminate in x.N is unknown.
Comment 1 Hang Yin 2012-01-19 12:24:11 CET
This is a pipe-and-filter system consisting of two components a and b. The system has one input and output. A data source generates new data to the system periodically. The system uses a counter to monitor the number of data being processed inside. The component connection is very simple. Data flow is like: Data source-->system-->a-->b-->system-->output. A threshold is defined to limit the maximal possible number of data simultaneously being processed in the system. When the threshold is reached, the data source will be turned off until the number of data in the system is smaller than the threshold again. Both a and b have input buffers. When they are not processing any data, the first data in the buffer will be processed immediately. a and b are also one group with atomic execution.
This is also a multi-mode system which can switch mode. A Mode Switch Request (MSR) could arrive at any time from a Mode Switch Triggering Source (MSTS). When the system receives the MSR, the data source is turned off and no more input data will enter the system until all the data currently being processed by the system are flushed away.

The purpose of the second and third property is to find out the worst-case latency introduced by the atomic execution of this group made of a and b, when a MSR arrives.
Comment 2 Hang Yin 2012-01-19 12:26:02 CET
Created attachment 254 [details]
The xml and q files of the model