<< Chapter < Page Chapter >> Page >
Trace
Given a state space automaton, a trace (sometimes called an -trace ) is a (possibly infinite) sequence of states 0 , 1 , 2 ,which respects the automaton's transtion relation T .

Thus a trace is a path through the state space (as we have already seen ). Now that we have logic propositions associated with each state,we can see that during a trace, those propositions will change their truth value over time.We'll illustrate this with diagrams like the following.

A timing diagram for a trace , and propositions p and q . Each propositional variable's value during the traceis depicted as a line. When the line is high, the proposition is true; when low, false.

In this example, p and q are propositions from Prop . Since in the trace , we have p being true at (for example) index 2, we write 2 p . In this diagram, it is also the case that 0 ( p q ) .

Technically, these diagrams are a bit too suggestive: a trace is only a sequence of discrete states,with no concept of time existing in between states. And the numbering of the x -axis is only an index to the sequence of statesit's not meant to imply that the system's states necessarily correspond to periodic samplings of our program.Yes, it would be more accurate to replace these continuous timelineswith a textual list of and (to represent the automaton's mapping P ). However, the diagrams better communicate information to us humans,especially those familiar with such timelines as used by hardware circuit designers.We just need to be careful not to read in between the times.

Although a bit unintuitive at first, it will be convenient to convert all finite traces into infinite ones.To do the conversion, we simply envision that once the automaton reaches its ostensibly last ( n th) state, it languishes furiously in that state over and over:

Stutter-Extend
The finite trace 0 , , n can be stutter-extended to the infinite trace 0 , , n , n , n , .

To ensure this still satisfies the definition of a trace (where successive states must obey the automaton's transition relation),it is often assumed that every state has a transition to itself. Note that this convention precludes assuming that somethingmust change between one state and the next, which is plausible since we are modeling asynchronous systems.This will be reflected in our formal logic below, which will have no built-in primitive for ``the-next-state''.

State formulas

Now that we have a formal model of what a trace is, we can start to make formal statements about what happens in a trace.The simplest statements are state formulas , i.e. , propositional formulas built out of Prop . For a given trace and state formula , we can immediately decide whethera particular state i satisifes (notationally, `` i '').

Deciding whether some particular state of a trace satisfies a formula also depends implicitly on the automaton . Technically we should write , i , though in practice is clear from context.

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Model checking concurrent programs. OpenStax CNX. Oct 27, 2005 Download for free at http://cnx.org/content/col10294/1.3
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Model checking concurrent programs' conversation and receive update notifications?

Ask