# Re: [tlaplus] How to model check this "real-time" spec?

Hi ns, this is my spec  to solve the problem, hope it can help:

-------------------------------- MODULE Time --------------------------------
(*turn lights on and off, but at least every K seconds*)
EXTENDS Naturals
CONSTANTS
MAX_TIME, K

Time == 0 .. MAX_TIME

VARIABLE lights,clock, lightsTrigT
vars == <<lights, clock, lightsTrigT>>

isTyped == lights \in BOOLEAN /\ clock \in Time /\ lightsTrigT \in Time

Init == lights=TRUE /\ clock=0 /\ lightsTrigT=0
\*Init == lights=FALSE /\ clock=10 /\ lightsTrigT=10

TBound(actionTriggerT, maxWait) == clock < actionTriggerT + maxWait

clockNext ==  /\ TBound(lightsTrigT, K)
/\ IF TBound(lightsTrigT, K-1)
THEN
/\ clock' = clock+1
/\ UNCHANGED <<lights,lightsTrigT>>
ELSE \*clock = (lightsTrigT + K -1)
/\ (IF lights THEN lights'=FALSE ELSE lights'=TRUE)
/\ clock' = clock+1
/\ lightsTrigT' = clock'

Next == clockNext

Spec == Init /\ [][Next]_vars

TimingOK == clock <= lightsTrigT + K

Test == clock # 10

THEOREM Spec => [] TimingOK

=============================================================================

First, you can of course ignore the deadlock by disabling deadlock checking if you are not interested in it.

Second, a state is deadlocked if `ENABLED Next' is false at that state, but the actual transition relation is [Next]_vars, so a finite behavior ending in a deadlocked state can always be extended to an infinite behavior.

Stephan

On 16 Oct 2021, at 06:23, ns <nedsr...@xxxxxxxxx> wrote:

But perhaps one answer here is that while the spec doesn't admit any traces in which the invariant is violated, it does admit finite traces (ie those that deadlock) and that is what TLC is catching. However, given TLA semantics, only infinite traces can be traces of the model so finite traces don't or shouldn't enter the picture.

On Friday, October 15, 2021 at 8:53:55 PM UTC-7 ns wrote:

On Sunday, October 10, 2021 at 2:19:32 AM UTC-7 Stephan Merz wrote:
Not sure I understand your question: TLC *does* model check your spec, it just (correctly) signals a deadlock, since the non-clock variables may stutter according to DoNothing until the clock exceeds its bound, at which point no action is enabled anymore. If you intend to avoid this, DoNothing needs a stronger time bound, see attached module for a possible definition.

Since the modified spec generates an unbounded state space, you'll need to add a state constraint to your model, such as

clock <= MAX_TIME

Hope this helps,
Stephan

--
You received this message because you are subscribed to the Google Groups "tlaplus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tlaplus+u...@xxxxxxxxxxxxxxxx.