If one accepts the assumption that the execution time of an automaton can be zero than one has the problem how to manage the dense real-time points within the system. In this case a run becomes a mapping from the real numbers into the set of possible states organized as an execution. Because in this scenario a definite succesor of a processing state q at time point t does no longer exist, because there can be infinite many possible time points as successors, one changed the definitions of CTL in a way, that in the extended version timed CTL (TCTL) the description of a run can be done without an explicit next operator X.
The other difference between CTL and TCTL is given by the fact that you can in TCTL extend the quantified formulas as follows:
This means e.g. that an expression like does not only talk about an execution where you have two different properties at position and at position with , but you can also give a numerical bound with . This numerical bound means that the property has to be reached in the run latest after 5 time units.
Because we are holding in this course the assumption that the processing time is always greater than zero we do not really need this special version of TCTL. Otherwise the explicit numerical bound has some practical flavor. Therefore we will define here a variant of timed CTL which is between CTL and TCTL, we call it tiny temporal CTL (tCTL). In the tiny CTL specification language we have all expressions from TCTL, but the main difference is that the indices used in tCTL correspond in the model structure to the operation cycles of the automaton (the above mentioned discrete automata time, DAT).
Before we define the syntax and semantics for the tCTL-expressions we have to extend our definition for the automaton with clocks by an additional term for properties, because the tCTL-expressions presuppose the existence of properties connected to the states.
Def.: Automata with Clocks and Properties
Thus, if we have a run of the automaton then we can deduce from this run for every state the set of attached properties as well as the implied output. We can then use the set of all possible executions of th automaton alpha as our model to define an interpretation relation for an tCTL-expression like
Example: We merge the automaton having properties like those in figure 3.4 with an automaton having clocks (cf. figure 5.4).
We want to check whether the following tCTL-formula is valid for this concrete automaton:
Question:
Answer: We construct a run as follows (we write the complete state description to show why the run is working):
This shows the following: there is a run . There is a position with state and according to we have there the attached property . Furthermore does hold . therefore we can conclude that the tCTL-formula is satisfied in , i.e. the formula is true in the model.
Gerd Doeben-Henisch 2010-03-03