Spin Tutorial some verification options Assertion is always

Spin Tutorial (some verification options)

Assertion • is always executable and has no other effect on the state of the system than to change the local control state of the process that executes it. • can trap violations of simple safety properties during verification and simulation runs with Spin. • EXAMPLES – assert(a > b) – assert(false) - to mark locations that are required, or assumed, to be unreachable • Argument: any valid Promela expression. The expression is evaluated each time the statement is executed. If the expression evaluates to false (or, equivalently, to the integer value zero), an assertion violation is reported.

End-state label (1) • is any label name that starts with the three-character sequence end. • can be used in proctype, trace, and notrace declarations. • in a proctype declaration, the end-state label marks a local control state that is acceptable as a valid termination point for all instantiations of that proctype. • In an event trace definition, the end-state label marks a global control state that corresponds to a valid termination point for the system as a whole. • If used in an event notrace definition, the event trace is considered to have been completely matched when the end state is reached, thus signifying an error condition.

End-state label (2) • EXAMPLE The expected termination point of the process is at the start of the loop. active proctype dijkstra() { end: do : : sema!p -> sema? v od } • Invalid end-state if the system with this proctype declaration can terminate in a state where the process of type dijkstra remains at the control state that exists just after the arrow symbol.

trace, notrace (1) • states a correctness requirement on existing behavior. • All channel names referenced in a trace or notrace declaration must be globally declared message channels, and all message fields must either be globally known constants, or _ to specify don't care conditions. • If only send operations on a channel appear in the trace, then only send operations on that channel are subject to the check. The same is true for receive operations. If both types appear, both are subject to the check, and they must occur in the relative order that the trace declaration gives. • An event trace causes a correctness violation if a send or receive action is executed in the system that is within the scope of the event trace, but that cannot be matched by a monitored event within that declaration. • An event trace declaration must always be deterministic.

trace, notrace (2) • A trace declaration specifies behavior that must be matched by the remainder of the specification, and a notrace declares behavior that may not be matched. • EXAMPLE trace { do : : opencloseddoor? _, 0; opencloseddoor? _, 1 od }

progress labels • used to define correctness claims • the labeled global state must be visited infinitely often in any infinite system execution • any violation can be reported by the verifier as a non-progress cycle. • active proctype dijkstra() { do : : sema!p -> progress: sema? v od }

accept label • is any label name that starts with the six-character sequence accept. • It can appear anywhere as a prefix to a Promela statement, but it is most often used inside never claims • There can be any number of accept labels in a model. • The Spin generated verifiers can prove either the absence or presence of infinite runs that traverse at least one accept state in the global system state space infinitely often. The mechanism can be used, for instance, to prove LTL liveness properties. • EXAMPLE The accept label in this model formalizes the requirement that the second state cannot persist forever, and cannot be revisited infinitely often either. In the given program this would imply that the execution should eventually always stop at the initial state, just before the execution of sema!p. active proctype dijkstra() { do : : sema!p -> accept: sema? v od }

never claims • Never claims can either be written by hand or they can be generated mechanically from LTL formula • defines system behavior that, for whatever reason, is of special interest. It is most commonly used to specify behavior that should never happen. • A never claim can be used to match either finite or infinite behaviors. – Finite behavior is matched if the claim can reach its final state (that is, its closing curly brace). – Infinite behavior is matched if the claim permits an omegaacceptance cycle. – Never claims, therefore, can be used to verify both safety and liveness properties of a system.

LTL properties

Weak (Process) Fairness • Enabling weak fairness (for processes) • if a process reaches a point where it is eager to execute a statement and the statement remains enabled, the process will eventually proceed with execution of this statement.

Merging statements: atomic and d_step • Both atomic and d_step are used to specify sequences of statements that are executed as one step, i. e. no interleavings • atomic: – a sequence can be non-deterministic – a statement inside a sequence is blocked => atomicity is broken, but can proceed as non-atomic • d_step: – a sequence is always deterministic – blocked statement inside a sequence causes an error • changes within atomic and d_step are not visible