**2. Timed automata**

Timed Automata (Alur & Dill, 1994) was proposed by Alur and improved by Dill. Timed Automata are finite machines equipped with sorts of clocks. Clocks: (1) are real functions with continuous time that record the times between the events separately and (2) are increased equally. Timed Automata are introduced as a formal specification for modeling the behavior of real time systems. Timed Automata are: (1) general methods for exhibition of timed transition state diagrams that use a number of time variables having real amounts, (2) finite clocked automata to specify the timed systems and (3) suitable for verification of distributed systems, optimization, verification of multi-tasking programs, network analysis, planning and scheduling (Paneka et al, 1998).

In Timed Automat, a safe path from the first state to a final state is a set of states in which actions are performed and timed requirements are satisfied. If such path is found, it is a solution for the problem. Timed Automata are stated in tuple M=(∑, S, S0, X, E) in which ∑ is a finite set of actions, *S* is a finite set of states, *S*0 is a finite set of initial states (S0 ⊂S), X is a finite set of clocks and *E* is a set of transitions. Every transition consists of <L, a, g, λ, L'>. A transition from present state L to the next state *L*' is made when the action *a* is performed and clock g(x) having true amount is passed. Notation *λ* is a subset of *X* during which the transition will be reset. Relation 1 states that clock values or difference of two clock values are real numbers.

$$\mathfrak{g} :: \mathtt{x} \& | \mathtt{c} \& | \mathtt{x} \cdot \mathtt{y} \& | \mathtt{x} \lhd \mathtt{c} | \mathtt{c} \lhd \mathtt{x} | \mathtt{x} \cdot \mathtt{y} \lhd \mathtt{c} | \mathtt{g} \land \mathtt{g} | \mathtt{true} \text{ that } \mathtt{x}, \mathtt{y} \in \mathtt{X}, \mathtt{c} \in \mathtt{R} \tag{1}$$

### **2.1 Networks of timed automata**

In this section, we dene networks of Timed Automata, consisting of several Timed Automata running in parallel and communicating with each other.

**Denition.** A timed automaton (TA, for short) is a six-element tuple, <sup>0</sup> ϑ= (A,L,l ,E,X,I)

Where


130 Real-Time Systems, Architecture, Scheduling, and Application

weakness of this method. We can use methods that are based on logic for reasoning and timing the Timed Automata. In this chapter, we suggest a framework for setting and executing Timed Automata using *Real Time Logic* (RTL) providing a reasoning framework based on *First Order Logic* (FOL). RTL reflects a different method for timed systems (Paneka

In this chapter, we show that Timed Automata per se is not able to show constraints of the systems, but if it is used with formal textual language such as RTL, expressing the

This chapter includes four sections: (1) in the second section, we express a brief explanation about Timed Automata, (2) in the third one we address an explanation about Real Time Logic and (3) in fourth section we express our approach to simulate Timed Automata by means of Real Time logic. In this section, we propose a case study and specify it using Timed Automata and Real Time logic. Then, we discuss the system constraints to supervise

Timed Automata (Alur & Dill, 1994) was proposed by Alur and improved by Dill. Timed Automata are finite machines equipped with sorts of clocks. Clocks: (1) are real functions with continuous time that record the times between the events separately and (2) are increased equally. Timed Automata are introduced as a formal specification for modeling the behavior of real time systems. Timed Automata are: (1) general methods for exhibition of timed transition state diagrams that use a number of time variables having real amounts, (2) finite clocked automata to specify the timed systems and (3) suitable for verification of distributed systems, optimization, verification of multi-tasking programs, network analysis,

In Timed Automat, a safe path from the first state to a final state is a set of states in which actions are performed and timed requirements are satisfied. If such path is found, it is a solution for the problem. Timed Automata are stated in tuple M=(∑, S, S0, X, E) in which ∑ is a finite set of actions, *S* is a finite set of states, *S*0 is a finite set of initial states (S0 ⊂S), X is a finite set of clocks and *E* is a set of transitions. Every transition consists of <L, a, g, λ, L'>. A transition from present state L to the next state *L*' is made when the action *a* is performed and clock g(x) having true amount is passed. Notation *λ* is a subset of *X* during which the transition will be reset. Relation 1 states that clock values or difference of two clock values

g::=x≤c|c≤x|x-y≤c|x<c|c<x|x-y<c|g∧g|true that x,y ∈X, c∈R (1)

In this section, we dene networks of Timed Automata, consisting of several Timed

ϑ

= (A,L,l ,E,X,I)

Automata running in parallel and communicating with each other.

**Denition.** A timed automaton (TA, for short) is a six-element tuple, <sup>0</sup>

et al, 2006).

unsafe states.

**2. Timed automata** 

are real numbers.

Where

**2.1 Networks of timed automata** 

constraints of the system would by more.

planning and scheduling (Paneka et al, 1998).


Each element *e* of *E* is denoted by a,cc,X l l' ⎯⎯⎯→ represents a transition from the location l to the location l' , executes the action a , with the set X ⊆ χ of the clocks to be reset, and with the clock constraint cc defining an enabling condition. The function I assigns each location l L ∈ a clock constraint defining the conditions under which ϑcan stay in l .

If the enabling conditions and the values of the location invariant are in the set CX only, then the automaton is called *diagonal-free*. Given the transition a,cc,X e:l l' ⎯⎯⎯→ , we write source(s), action(s), target(s), guard(s) and reset(s) for l,l',a,cc and X, respectively. The clocks in Timed Automata allow expressing the time properties. An enabling condition constrains the execution of a transition. An invariant condition permits an automaton to stay at the location l as long as the clock constraint I(l) is satisfied.

Real-time systems are usually represented by networks (sets) of Timed Automata. A typical example widely considered in the literature, is modeling an automated railroad crossing (known as the Train–Gate–Controller).

A set of timed automata can be composed into a global (product) timed automaton as follows: the transitions of the timed automata that do not correspond to a shared action are interleaved whereas the transitions labeled with a shared action are synchronized. There are many different denitions for a parallel composition. One definition is determining the multi-way synchronization, i.e., each component that contains a communication transition (labeled with a shared action) has to perform this action (Penczek & Polrola, 2006).

**Definition**. Let 1 n {i ,...,i } λ = λ be a finite ordered set of indices, and i ζ = ∈ { |i } ϑ λ where 0 i i ii i ii ϑ = (A ,L ,l ,E ,X ,I ), is a set (network) of Timed Automata indexed with λ . The automata in ζ are called components. Let A(a) {i |a A } =∈ ∈ λ i be a set of the indices of the components containing the action i i a A ∈ <sup>∈</sup>λ . A composition (product) of the Timed Automata 1 n i i ||...|| λϑ ϑ is a timed automaton specified as: <sup>0</sup> ϑ= (A,L,l ,E,X,I) , where


And the *transition relation* is given as Relation 2.

$$\begin{aligned} (\mathbf{l}\_{\mathbf{i}\_{1}}\iota\ldots\mathbf{l}\_{\mathbf{i}\_{\mathbf{a}\boldsymbol{\lambda}}}), \mathbf{a}\_{\wedge}\wedge\_{\mathbf{i}\in\mathbf{A}\{\mathbf{a}\}}\mathbf{c}\_{\mathbf{i}\_{1}}\mathsf{U}\_{\mathbf{i}\in\mathbf{A}\{\mathbf{a}\}}\mathsf{X}\_{\mathbf{i}'}(\mathbf{l}\_{\mathbf{i}\_{1}}^{\flat}\ldots\mathbf{l}\_{\mathbf{i}\_{\mathbf{a}\boldsymbol{\lambda}}}^{\flat})\in\mathcal{E}\Leftrightarrow\\ (\forall\mathbf{i}\in\mathbf{A}(\mathbf{a}))(\mathbf{l}\_{\mathbf{i}'}\mathbf{a}, \mathbf{c}\mathbf{c}\_{\mathbf{i}'}\mathcal{X}\_{\mathbf{i}'}\mathbf{l}\_{\mathbf{i}}^{\flat})\in\mathcal{E}\_{\mathtt{i}}\text{and}(\forall\mathbf{i}\in\mathcal{A}\,\!\!\backslash\mathbf{A}(\mathbf{a}))\mathbf{l}\_{\mathbf{i}}^{\flat}=\mathbf{l}\_{\mathbf{i}}.\end{aligned} \tag{2}$$

Construction of Real-Time Oracle Using Timed Automata 133

Performing an action is shown by starting and ending events [4]. Events have unique name and the capital letters are used for showing them. To show the external events, we use notation Ω before the name of an event. Also notation ↑ is used before the name of an event to show a starting event (denoted by ↑A) and notation ↓ to show an ending event (denoted by ↓A). Propositions of RTL are the relations between occurrences of the events using orderings < , = , >, ≥ ,≤ (Jahanian-b et al, 1998). The RTL formulas are made of equal/unequal, existential forms, quantifiers ∀ and ∃ and logical relations, ∧∨→¬ ,, , (Jahanian, 1994). A function is used to show the time of the occurrence of an event and allocation of an amount of time to the occurrence of the event. It is shown by notation "@". Relation "@(e,i)" denotes the ith occurrence of event *e* where *e* can be a starting or

Consider a system specified in a natural language; the system samples and displays data on demand by external stimuli. Upon pressing button #1, action SAMPLE is executed within 30 time units. During each execution of this action, data are sampled and subsequently appeared in the display panel. The computation time of action SAMPLE is 20 time units. The

> [ x,yR( SAMPLE,i,x) R( SAMPLE,i,y)tx y t 30] i x,y[R( SAMPLE,i,x) R( SAMPLE,i,y)] x 20 y

In this section, we introduce the RTL language; the following notations are used in RTL

The *time terms* in RTL consist of constants, variables and if t 1 and t 2 are time terms, then t 1 + t2 is a time term. The *occurrence terms* in RTL are expressions consisting of constants,

variables and if *i* and *j* are occurrence terms, then i + j is an occurrence term.

∃ ↑ ∧ ↓ ∧≤ ∧ ≤+ ∀∀ ↑ ∧ ↓ →+ ≤

following set of formulas is a partial description of the system in RTL:

i tR( BUTTON1,i,t)

→

Ω

• C, constants including the natural numerals

• Logical connections: ∧ , ∨ , ¬ and → • Existential and universal quantifiers: ∀ , ∃ .

1. External event like pushing a button by the user, 2. The starting event denoting the beginning of an action. 3. The ending event denoting the completion of an action,

external event (Jahanian-a et al, 1998).

∀ ∀

**3.1 The RTL Language** 

• *A*, set of time variables • *B*, set of occurrence variables

formulae:

• true and false

• D, set of events • Function +

• Predicates , , , , ≤≥<>= • Occurrence relation *R* 

**Example:** 

#### **2.2 Semantics of timed automata**

Let <sup>0</sup> ϑ = (A,L,l ,E,X,I) be a timed automaton. A concrete state of A is defined as ordered pair(l,v), where l L ∈ and nx v IR ∈ <sup>0</sup><sup>+</sup> is a valuation. The *concrete (dense) state space* ϑ is a *transition system*, <sup>0</sup> C ( ) (Q,q , ) <sup>c</sup> <sup>c</sup> ϑ= ⎯⎯→ where


A time successor is defined as Relation 3.

$$\text{for } \delta \in \text{IR}\_{0+}(\mathbf{l}, \mathbf{v}) \xrightarrow{\delta} \text{\text{\textquotedblleft}l} \text{\textquotedblright}(\mathbf{l}, \mathbf{v} + \delta) \\ \text{iff } \mathbf{v}, \mathbf{v} + \delta \in \|\mathbf{l}\| \|\text{\textquotedblleft}\|\text{\textquotedblright}\|\text{\textquotedblright}\tag{3}$$


Intuitively, a time successor does not change the location l of a concrete state, but it increases the clocks, provided that their values still satisfy the invariant l . Since the invariants are zones, if v and v' satisfy I(l) , then all the clocks between v and v' satisfy I(l) . An action successor corresponding to the action a is executed when the guard cc holds for v and v' obtained after resetting the clocks in X , satises the invariant l' .

For (l,v) Q∈ and <sup>0</sup> δ ∈IR <sup>+</sup> , let (l,v) + δ denotes (l,v ) + δ . Concatenation of two time steps q qc δ ⎯⎯→ + δ and ' q q' <sup>c</sup> δ + ⎯⎯ δ δδ → ++ is the time step ' q q' <sup>c</sup> δ δ δ δ ⎯⎯⎯+ → ++ . Similarly, if q qc δ ⎯⎯→ + δ, then for any δ there exist:

$$\delta\_1, \dots, \delta\_k \in \text{IR}\_{0\*} \text{ where, } \delta\_1 + \dots + \delta\_k = \delta \text{ & } \mathbf{q} \xrightarrow{\delta\_1} \dots \mathbf{q} + \delta\_1 \xrightarrow{\delta\_2} \dots \xrightarrow{\delta\_k} \mathbf{q} + \delta \text{ & } \mathbf{r} \xrightarrow{\delta\_k} \mathbf{q} + \delta \text{ & } \mathbf{r} \xrightarrow{\delta\_k} \dots \mathbf{q} + \delta$$

The second relation denotes that each time step can be split into an arbitrary number of consecutive times. A (dense) q0 -run ρ of ϑis a maximal (i.e., non-extendable) sequence,

$$\rho = \mathbf{q}\_0 \xrightarrow{\delta\_0} \mathbf{c}\_c \mathbf{q}\_0 + \delta\_0 \xrightarrow{\mathbf{a}\_0} \mathbf{c}\_1 \xrightarrow{\delta\_1} \mathbf{q}\_1 + \delta\_1 \xrightarrow{\mathbf{a}\_1} \mathbf{c}\_c \mathbf{q}\_2 \xrightarrow{\delta\_2} \cdots$$

where <sup>i</sup> a A∈ and i 0 δ ∈IR <sup>+</sup> ,for each i N≥ (notice that due to the fact that δ can be equal to zero, two consecutive transitions can be executed without any time passing in between, and that consecutive time passages are concatenated). Such runs are called weakly monotonic (Penczek & Polrola, 2006).

### **3. Real Time Logic**

Real Time Logic (RTL) introduced by Jahanian and Mok in 1986, is an FOL having a set of elements for specification of requirements of real time systems (Bellini et al, 2000). The logic is a formal language used for reasoning about time characteristics of the real time systems. RTL deals with ordering of the events (Jahanian-a, 1998). There is a significant difference between event and action in RTL (Jahanian-b et al, 1998).

There are four types of events:


Performing an action is shown by starting and ending events [4]. Events have unique name and the capital letters are used for showing them. To show the external events, we use notation Ω before the name of an event. Also notation ↑ is used before the name of an event to show a starting event (denoted by ↑A) and notation ↓ to show an ending event (denoted by ↓A). Propositions of RTL are the relations between occurrences of the events using orderings < , = , >, ≥ ,≤ (Jahanian-b et al, 1998). The RTL formulas are made of equal/unequal, existential forms, quantifiers ∀ and ∃ and logical relations, ∧∨→¬ ,, , (Jahanian, 1994). A function is used to show the time of the occurrence of an event and allocation of an amount of time to the occurrence of the event. It is shown by notation "@". Relation "@(e,i)" denotes the ith occurrence of event *e* where *e* can be a starting or external event (Jahanian-a et al, 1998).

### **Example:**

132 Real-Time Systems, Architecture, Scheduling, and Application

= (A,L,l ,E,X,I) be a timed automaton. A concrete state of A is defined as ordered

δ

ϑis a

(Time successor), (3)

. Concatenation of two time steps

δ

→ ⎯⎯→ + .

δ

 δ

can be equal to

δ δ⎯⎯⎯+ → ++ . Similarly, if

pair(l,v), where l L ∈ and nx v IR ∈ <sup>0</sup><sup>+</sup> is a valuation. The *concrete (dense) state space* 

⎯→⊆ ∪ Q \* (E IR ) \* Q <sup>0</sup><sup>+</sup> is the transition relation, defined by an action

 δ∈ ⎯⎯ <sup>+</sup> → + v,v I(l) + ∈

Intuitively, a time successor does not change the location l of a concrete state, but it increases the clocks, provided that their values still satisfy the invariant l . Since the invariants are zones, if v and v' satisfy I(l) , then all the clocks between v and v' satisfy I(l) . An action successor corresponding to the action a is executed when the guard cc holds

denotes (l,v ) +

The second relation denotes that each time step can be split into an arbitrary number of

0 01 <sup>2</sup> <sup>a</sup> a1 c cc cc q q q q q ... 0 00 1 11 2 δδδ

= ⎯⎯→ + ⎯⎯→ ⎯⎯→ + ⎯⎯→ ⎯⎯→

∈IR <sup>+</sup> ,for each i N≥ (notice that due to the fact that

zero, two consecutive transitions can be executed without any time passing in between, and that consecutive time passages are concatenated). Such runs are called weakly monotonic

Real Time Logic (RTL) introduced by Jahanian and Mok in 1986, is an FOL having a set of elements for specification of requirements of real time systems (Bellini et al, 2000). The logic is a formal language used for reasoning about time characteristics of the real time systems. RTL deals with ordering of the events (Jahanian-a, 1998). There is a significant difference

δ

 ++ = ... & 1 2 <sup>k</sup> c cc q q <sup>1</sup> ... q δ

> δ

δ δ

> δ

is a maximal (i.e., non-extendable) sequence,

 ⎯⎯→ + ⎯⎯ δ

→ ++ is the time step ' q q' <sup>c</sup>

• a,cc,X l l' E ⎯⎯⎯→ ∈ , v [cc] ∈ , v' v[X : 0],and = = v' I(l') ∈ (action successor).

for v and v' obtained after resetting the clocks in X , satises the invariant l' .

δ

 δδ

ρ of ϑ

 δδ

δ

= ⎯⎯→ where

• 0 00 q (l ,v ) = with <sup>0</sup> v (x) 0 = for all x X ∈ is the initial state, and

<sup>c</sup> <sup>0</sup> for IR ,(l,v) (l,v )iff δ

• For <sup>a</sup> <sup>c</sup> <sup>x</sup> a A,(l,v) (l',v')iff( cc C )( X x) ∈ ⎯⎯→ ∃∈ ∃⊆ such that

∈IR <sup>+</sup> , let (l,v) +

 and ' q q' <sup>c</sup> δ + ⎯⎯ δ

, then for any δ there exist:

,..., IR ∈ <sup>+</sup> where, 1 k

ρδ

between event and action in RTL (Jahanian-b et al, 1998).

**2.2 Semantics of timed automata** 

*transition system*, <sup>0</sup> C ( ) (Q,q , ) <sup>c</sup> <sup>c</sup> ϑ

A time successor is defined as Relation 3.

δ

For (l,v) Q∈ and <sup>0</sup>

δ

δ

where <sup>i</sup> a A∈ and i 0

(Penczek & Polrola, 2006).

There are four types of events:

**3. Real Time Logic** 

δ δ

1k 0

consecutive times. A (dense) q0 -run

δ

q qc δ⎯⎯→ +

q qc δ⎯⎯→ + δ

• nx Q L \* IR = <sup>0</sup><sup>+</sup> is the set of all the concrete states,

Let <sup>0</sup> ϑ

• ⎯<sup>c</sup>

Consider a system specified in a natural language; the system samples and displays data on demand by external stimuli. Upon pressing button #1, action SAMPLE is executed within 30 time units. During each execution of this action, data are sampled and subsequently appeared in the display panel. The computation time of action SAMPLE is 20 time units. The following set of formulas is a partial description of the system in RTL:

> i tR( BUTTON1,i,t) [ x,yR( SAMPLE,i,x) R( SAMPLE,i,y)tx y t 30] i x,y[R( SAMPLE,i,x) R( SAMPLE,i,y)] x 20 y ∀ ∀ Ω → ∃ ↑ ∧ ↓ ∧≤ ∧ ≤+ ∀∀ ↑ ∧ ↓ →+ ≤

#### **3.1 The RTL Language**

In this section, we introduce the RTL language; the following notations are used in RTL formulae:


The *time terms* in RTL consist of constants, variables and if t 1 and t 2 are time terms, then t 1 + t2 is a time term. The *occurrence terms* in RTL are expressions consisting of constants, variables and if *i* and *j* are occurrence terms, then i + j is an occurrence term.

Construction of Real-Time Oracle Using Timed Automata 135

RTL provides nine different *state predicates* to evaluate the value of S over an interval as

S[x,y], S(x,y), S<x,y>, S[x,y), S[x,y>, S(x,y], S(x,y>, S<x,y], S<x,y) Each state predicate qualifies the timing of two events, one denotes the transition event that changes the value of the state variable to true and the other denotes the transition event that changes the value of S to false. The arguments, x and y, in the state predicates are used in conjunction with the symbols "[", "]", "(", ")", "<" and ">" to denote an interval over which the state variable remains true (Jahanian, 1994). Suppose Et and Ef denote the transition events

**3.2 State predicates** 

making S true and false, respectively. Informally:



**Definition**: If state variable S is initially true, i.e., R((S : T),1,0) = , then

S[x,y] i,R((S : T),i,x) R((S : F),i,y)

≡∃ = ∧ =

S[x,y) i,R((S : T),i,x) [ tR((S : F),i,t) y t] S[x,y i,R((S : T),i,x) [ tR((S : F),i,t) y t]

The other intervals are defined similarly. If state variable S is initially false, i.e., R((S : F),1,0) = , then S[x,y] iR((S : T),i,x) R((S : F),i 1, ≡∃ = ∧ = + y). The other intervals are

In this section, we propose a method to produce verification rules from Timed Automata. These rules are used for verification of the software behavior that is obtained from the problem specification. Our method has five steps (Fig.1). In the first step, we specify the

≡∃ = ∧ ∀ = → ≤ >≡ ∃ = ∧ ∀ = → <


defined similarly (Jahanian-b , 1998).

**4. The proposed approach** 

follows:

[ t'R((S : T),i,t') t' t] i tR((S : T),i 1,t) ∃ = ∧ < ∧∀∀ = + → (4c)

[ t'R((S : F),i,t') t' t] i tR((S : F),i 1,t) ∃ = ∧ < ∧∀∀ = + → (5c)

[ t'R((S : F),i,t') t' t] ∃ = ∧< (4d)

R((S : F),1,0) = → (5a)

( i tR((S : T),i,t) ∀∀ = → (5b)

[ t'R((S : T),i,t') t' t] ∃ = ∧< (5d)

The propositions in RTL consist of truth symbols, *true* and *false* and:


The formulas of RTL are constructed from the propositions, logical connections and quantifiers.

**Definition**: An occurrence relation is a relation on the set E × Z+ × N where E is a set of events, **Z+** is the set of positive integers, and **N** is the set of natural numbers, such that the following axioms hold:

**Monotonicity Axioms:** For each event *e* in the set D,

$$\begin{aligned} \forall \mathbf{i} \forall \mathbf{t} \forall \mathbf{t} \forall \mathbf{t} \left[ \mathbf{R} (\mathbf{e}, \mathbf{i}, \mathbf{t}) \land \mathbf{R} (\mathbf{e}, \mathbf{i}, \mathbf{t}') \to \mathbf{t} = \mathbf{t}' \\ \forall \mathbf{i} \forall \mathbf{t} \big[ \mathbf{R} (\mathbf{e}, \mathbf{i}, \mathbf{t}) \land \mathbf{i} > \mathbf{1} \big] \to \left[ \exists \mathbf{t} \big[ \mathbf{R} (\mathbf{e}, \mathbf{i} - \mathbf{1}, \mathbf{t}') \land \mathbf{t}' < \mathbf{t} \big] \right] \end{aligned}$$

The first axiom states that at most onetime value can be associated with each occurrence *i* of an event *e*, i.e., two same occurrences of an event cannot happen at two distinct times. The second axiom expresses that if the *i*th occurrence of event *e* happens, then the previous occurrences of *e* would happened before. This axiom also states that two distinct occurrences of the same event must happen at different times.

**Start/Stop Event Axioms:** For each pair of start/stop events in the set **D**, we have:

$$\forall \mathbf{i} \forall \mathbf{t} \mathbf{R}(\Downarrow \mathbf{A}, \mathbf{i}, \mathbf{t}) \to \left[ \exists \mathbf{t} \, \text{'R}(\ulcorner \mathbf{A}, \mathbf{i}, \mathbf{t} \urcorner) \land \mathbf{t} \, \text{'<} \mathbf{t} \right].$$

where ↑A and ↓A denote the events: start and stop of action A, respectively. The axiom states that every occurrence of a stop event would be preceded by a corresponding start event.

**Transition Event Axioms**: For the transition events in the set *D* corresponding to a state variable *S***,** we have the following relations. Proposition 4(a) states that the first occurrence of event (S:=T) is at time zero. This means that initially the system is in state *S*. Proposition 4(b) states that ith occurrence of event (S:=F) is at time *t*. This means that ith time that the system is not in state *S* is at time *t*. The transition from 4(a) to 4(b) shows a *transition event* where the system is initially in state *S* and at future time the system is not in state *S*. The transition from 4(b) to 4(c) shows the entrance of the system to state *S* and the transition from 4(c) to 4(d) shows the exit of the system from state *S*. Transitions in 5(a) to 5(d) is similar to transitions in 4(a) to 4(d) but the system is not initially in state *S*. In fact, Propositions 4(a) to 4(d) and Propositions 5(a) to 5(d) define the order in which two complementary transition events can occur depending on whether S is initially true or false (Jahanian-b et al, 1998).

$$\mathbb{R}(\mathbb{S} \coloneqq \mathcal{T}), \mathbf{1}, \mathbf{0}) \to \tag{4a}$$

$$(\forall \mathbf{i} > \mathbf{1}, \forall \mathbf{t} > \mathbf{0}, \mathbb{R}((\mathbf{S} := \mathbf{F}), \mathbf{i}, \mathbf{t}) \to \\ \tag{4b}$$

$$\{\exists \mathbf{t}' \mathbf{R}((\mathbf{S} := \mathbf{T}), \mathbf{i}, \mathbf{t}') \land \mathbf{t}' < \mathbf{t} \} \land \forall \mathbf{i} \forall \mathbf{t} \newline \mathbf{R}((\mathbf{S} := \mathbf{T}), \mathbf{i} + \mathbf{1}, \mathbf{t}) \to \tag{4c}$$

$$\left[\exists \mathbf{t}\,\mathrm{'R}((\mathbf{S}\coloneqq\mathbf{F}),\mathbf{i},\mathbf{t'}) \land \mathbf{t}\,\mathrm{'$$

$$\text{R((S:=F),1,0)} \to \tag{5a}$$

$$(\forall \text{i} \forall \text{t} \text{R}((\text{S} \mathrel{\text{= T}}) \text{,} \text{t}) \rightarrow \tag{5b}$$

$$\{\exists \mathbf{t}' \mathbb{R}((\mathbf{S} := \mathbf{F}), \mathbf{i}, \mathbf{t}') \land \mathbf{t}' < \mathbf{t} \} \land \forall \mathbf{i} \forall \mathbf{t} \mathbb{R}((\mathbf{S} := \mathbf{F}), \mathbf{i} + \mathbf{1}, \mathbf{t}) \to \tag{5c}$$

$$\left[\exists \mathbf{t}\,\mathrm{'R}((\mathbf{S}\coloneqq\mathrm{T}),\mathbf{i},\mathbf{t'}) \land \mathbf{t}\,\mathrm{'} < \mathbf{t}\right] \tag{5d}$$

#### **3.2 State predicates**

134 Real-Time Systems, Architecture, Scheduling, and Application




The formulas of RTL are constructed from the propositions, logical connections and

**Definition**: An occurrence relation is a relation on the set E × Z+ × N where E is a set of events, **Z+** is the set of positive integers, and **N** is the set of natural numbers, such that the

i t[R(e,i,t) i 1] [ t'R(e,i 1,t') t' t]

The first axiom states that at most onetime value can be associated with each occurrence *i* of an event *e*, i.e., two same occurrences of an event cannot happen at two distinct times. The second axiom expresses that if the *i*th occurrence of event *e* happens, then the previous occurrences of *e* would happened before. This axiom also states that two distinct

∀∀ ↓ → ∃ ↑ ∧ < i tR( A,i,t) [ t'R( A,i,t') t' t]

where ↑A and ↓A denote the events: start and stop of action A, respectively. The axiom states that every occurrence of a stop event would be preceded by a corresponding start

**Transition Event Axioms**: For the transition events in the set *D* corresponding to a state variable *S***,** we have the following relations. Proposition 4(a) states that the first occurrence of event (S:=T) is at time zero. This means that initially the system is in state *S*. Proposition 4(b) states that ith occurrence of event (S:=F) is at time *t*. This means that ith time that the system is not in state *S* is at time *t*. The transition from 4(a) to 4(b) shows a *transition event* where the system is initially in state *S* and at future time the system is not in state *S*. The transition from 4(b) to 4(c) shows the entrance of the system to state *S* and the transition from 4(c) to 4(d) shows the exit of the system from state *S*. Transitions in 5(a) to 5(d) is similar to transitions in 4(a) to 4(d) but the system is not initially in state *S*. In fact, Propositions 4(a) to 4(d) and Propositions 5(a) to 5(d) define the order in which two complementary transition events can occur depending on whether S is initially true or false (Jahanian-b et al, 1998).

R((S : T),1,0) = → (4a)

( i 1, t 0,R((S : F),i,t) ∀> ∀> = → (4b)

∀∀ ∧ > → ∃ − ∧ <

i t t'[R(e,i,t) R(e,i,t') t t'

**Start/Stop Event Axioms:** For each pair of start/stop events in the set **D**, we have:

∀∀∀ ∧ → =

The propositions in RTL consist of truth symbols, *true* and *false* and:

proposition

proposition.

following axioms hold:

**Monotonicity Axioms:** For each event *e* in the set D,

occurrences of the same event must happen at different times.

quantifiers.

event.

*j* is a proposition

RTL provides nine different *state predicates* to evaluate the value of S over an interval as follows:

$$\text{S[x,y],S(x,y),S\curvearrowright,S[x,y),S[x,y>,S(x,y)],S(x,y>,S\curvearrowright,S\curvearrowright,S\curvearrowright)}$$

Each state predicate qualifies the timing of two events, one denotes the transition event that changes the value of the state variable to true and the other denotes the transition event that changes the value of S to false. The arguments, x and y, in the state predicates are used in conjunction with the symbols "[", "]", "(", ")", "<" and ">" to denote an interval over which the state variable remains true (Jahanian, 1994). Suppose Et and Ef denote the transition events making S true and false, respectively. Informally:


**Definition**: If state variable S is initially true, i.e., R((S : T),1,0) = , then

$$\begin{aligned} \mathsf{S}[\mathbf{x}, \mathbf{y}] & \equiv \exists \mathbf{i}, \mathsf{R}((\mathbf{S} := \mathbf{T}), \mathbf{i}, \mathbf{x}) \land \mathsf{R}((\mathbf{S} := \mathbf{F}), \mathbf{i}, \mathbf{y})\\ \mathsf{S}[\mathbf{x}, \mathbf{y}) & \equiv \exists \mathbf{i}, \mathsf{R}((\mathbf{S} := \mathbf{T}), \mathbf{i}, \mathbf{x}) \land \left[ \forall \mathsf{tR}((\mathbf{S} := \mathbf{F}), \mathbf{i}, \mathbf{t}) \rightarrow \mathbf{y} \leq \mathbf{t} \right] \\ \mathsf{S}[\mathbf{x}, \mathbf{y} & \coloneqq \exists \mathbf{i}, \mathsf{R}((\mathbf{S} := \mathbf{T}), \mathbf{i}, \mathbf{x}) \land \left[ \forall \mathsf{tR}((\mathbf{S} := \mathbf{F}), \mathbf{i}, \mathbf{t}) \rightarrow \mathbf{y} < \mathbf{t} \right] \end{aligned}$$

The other intervals are defined similarly. If state variable S is initially false, i.e., R((S : F),1,0) = , then S[x,y] iR((S : T),i,x) R((S : F),i 1, ≡∃ = ∧ = + y). The other intervals are defined similarly (Jahanian-b , 1998).

### **4. The proposed approach**

In this section, we propose a method to produce verification rules from Timed Automata. These rules are used for verification of the software behavior that is obtained from the problem specification. Our method has five steps (Fig.1). In the first step, we specify the

Construction of Real-Time Oracle Using Timed Automata 137

**Structure 2**. Change of a state by occurrence of an event and the action execution. After

**Visual definition**. When the system (Timed Automata) is in state p and a guard event

p q Guard, Action

**Logical definition of structure 2**. If the system is in the state *p* at time *t* and a guard event takes place, we have an occurrence of the starting event of the action denoted by ↑ACTION. This causes the start of the action and ending event of action denoted by ↓ACTION. The

↑

*t',d[q(t',t')* 

↓

*ACTION,j)=t'* 

*ACTION,j)=t'* 

∧ *t'≥t+d* ∧ *d≥0]* 

∧ *t'≥t+d* ∧

∧ *t'≥ t+d* ∧ *d≥*ε*]* 

∀i ∀t[p(t,t)] (8)

 *d≥0]* (7)

occurring the event and the action execution, the state of the system might change.

occurs, the action is accomplished and the system holds in state q (Fig. 3).

Fig. 3. Change of a state by occurrence of an event and execution of an action

action is accomplished during the time ε>0 and the state changes (Relation 7).

→ ∃*j,t',d[@(*

*ACTION,i)=t]* 

→ ∃*j,t',d[@(*

> → ∃

**Structure 3**. Being in one state. In real time systems, a state indicates the system state at a

**Visual definition**. According to Fig. 2, when the system is in state *p*, the state indicates the

**Logical definition of structure 3**. This structure shows that state *p* is true at time t. In other

**Structure 4**. Remaining in a state and change of the state. The system should stay in a state

**Visual definition**. When the system is in state L1, it should stay in this state at least for time unit d. After passing of the time and satisfaction of the condition, it would enter to state L2

L0 L1

**Logical definition of structure 4**. If the system is in state L1 after satisfaction of condition

c<=d

∀i ∀t[L1(t,t) ∧ @(COND (c<=d) , i) = t]→ ∃ t' [L1(t',t') ∧ t' ≥ t+d ∧ d≥ ε] (9)

L2

 *@(GUARD,i)=t ]*

*ACTION,i)=t]* 

∀*i* ∀*t[p(t,t)* ∧

time instant/interval .

(Fig. 4).

∀*i* ∀*t[@(*↑

> ∀*i* ∀*t[@(*↓

current state of the system at that specific moment.

words, the system is in state *p* at time t (Relation 8).

for a while and then the state should change.

Fig. 4. Change of a state (C indicates clock)

(c<=d) at time t, it would go to a new state (Relation 9).

system behavior in the Timed Automata and then verify the different states of the system. In the second step, we explain specification of the system in RTL. In the third step, based on the model of the Timed Automata, we work out the reachability graph of the system, and show the behavior of the system in safety and risky states. In the fourth step, we use reachability graph obtained in the third step to extract constraints and express them in RTL by which we verify entering the system to unsafe states.

After specifying the system constraints in RTL and specification of the system behavior by the model in the second step, we verify the problem specification (in fact, we show a visual model of the system in Timed Automata and its behavior in RTL. By the rules extracted from the system behavior, we address verification of the system in entering to unsafe states

Fig. 1. The proposed approach

## **4.1 Specifying the problem in timed automata**

In this section, we show states of a real time system in the visual and logic forms.

**Structure 1**: Change of a state due to occurrence of an event. The change of a state in real time systems might be taken place due to occurrence of an event.

**Visual definition**. When the system is in state *p* and a guard event takes place, the system makes a transition from state *p* to state *q* (Fig. 2).

Fig. 2. Change of a state by occurrence of a guard event

**Logical definition of structure 1**. When the system is in state *p* at time point *t*, then by *i*th occurrence of guard event at time *t*, the system goes to state *q* (Relation 6). Considering state predicates in Section 3.2, we define a time point as p(t,t).

$$\forall \mathbf{i} \; \forall \mathbf{t} [\mathbf{p}(\mathbf{t}, \mathbf{t}) \; \land \; \oplus (\mathbf{G} \mathbf{U} \mathbf{A} \mathbf{R} \mathbf{D}, \mathbf{i}) \mathbf{=} \mathbf{t}] \rightarrow \exists \mathbf{t}', \mathbf{d} [\mathbf{q}(\mathbf{t}', \mathbf{t}') \; \land \; \mathbf{t}', \mathbf{\not\approx t} \; \land \; \mathbf{q} \,\mathbf{s} \, \mathbf{0}] \tag{6}$$

136 Real-Time Systems, Architecture, Scheduling, and Application

system behavior in the Timed Automata and then verify the different states of the system. In the second step, we explain specification of the system in RTL. In the third step, based on the model of the Timed Automata, we work out the reachability graph of the system, and show the behavior of the system in safety and risky states. In the fourth step, we use reachability graph obtained in the third step to extract constraints and express them in RTL

After specifying the system constraints in RTL and specification of the system behavior by the model in the second step, we verify the problem specification (in fact, we show a visual model of the system in Timed Automata and its behavior in RTL. By the rules extracted from the system behavior, we address verification of the system in entering to unsafe states

> 2. extraction of logic & specification of the problem

5. production of verification rules

by which we verify entering the system to unsafe states.

1. specification of the problem

3. extraction of the reachability

by Timed Automata

Fig. 1. The proposed approach

reachability graph

graph

**4.1 Specifying the problem in timed automata** 

4. specification of constraints by RTL from

makes a transition from state *p* to state *q* (Fig. 2).

Fig. 2. Change of a state by occurrence of a guard event

predicates in Section 3.2, we define a time point as p(t,t).

In this section, we show states of a real time system in the visual and logic forms.

time systems might be taken place due to occurrence of an event.

**Structure 1**: Change of a state due to occurrence of an event. The change of a state in real

**Visual definition**. When the system is in state *p* and a guard event takes place, the system

**Logical definition of structure 1**. When the system is in state *p* at time point *t*, then by *i*th occurrence of guard event at time *t*, the system goes to state *q* (Relation 6). Considering state

p q guard

∀i ∀t[p(t,t) ∧ @(GUARD,i)=t ] → ∃t',d[q(t',t') ∧ t' ≥t+d ∧ d≥0] (6)

**Structure 2**. Change of a state by occurrence of an event and the action execution. After occurring the event and the action execution, the state of the system might change.

**Visual definition**. When the system (Timed Automata) is in state p and a guard event occurs, the action is accomplished and the system holds in state q (Fig. 3).

Fig. 3. Change of a state by occurrence of an event and execution of an action

**Logical definition of structure 2**. If the system is in the state *p* at time *t* and a guard event takes place, we have an occurrence of the starting event of the action denoted by ↑ACTION. This causes the start of the action and ending event of action denoted by ↓ACTION. The action is accomplished during the time ε>0 and the state changes (Relation 7).

$$\forall \mathbf{i} \; \forall \mathbf{j} (p(t, \mathbf{i}) \land \oplus (\text{GLARRD}, \mathbf{i}) \mathbf{i} = \mathbf{t} \; ] \rightarrow \exists \mathbf{j}, \mathbf{t}'. \mathbf{d}[\oplus (\uparrow \mathbf{A} \, \text{CTION}, \mathbf{j}) \mathbf{i} = \mathbf{t}' \land \mathbf{t}' \; \mathbf{2} \mathbf{t} + \mathbf{d} \land d\mathbf{2} \; \mathbf{0}] \tag{7}$$
 
$$\forall \mathbf{i} \; \forall \mathbf{j} (\oplus (\uparrow \mathbf{A} \, \text{CTION}, \mathbf{i}) \mathbf{i} = \mathbf{t}) \rightarrow \exists \mathbf{j}, \mathbf{t}'. \mathbf{d}[\oplus (\downarrow \mathbf{A} \, \text{CTION}, \mathbf{j}) \mathbf{i} \; \forall \mathbf{i} \; \forall \mathbf{j} \; \mathbf{t} + \mathbf{d} \land d\mathbf{2} \; \mathbf{e}]$$
 
$$\forall \mathbf{i} \; \forall \mathbf{j} [\oplus (\downarrow \mathbf{A} \, \text{CTION}, \mathbf{i}) \mathbf{i} \; \mathbf{j} = \mathbf{t}] \rightarrow \exists \mathbf{i}'. d[\![q(\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \; \mathbf{2} \land \mathbf{t} \land d\mathbf{2} \; \mathbf{0}] \; \mathbf{i} \; \forall \mathbf{j} \; \mathbf{d} \; \mathbf{d} \; \mathbf{0} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d} \; \mathbf{d}$$

**Structure 3**. Being in one state. In real time systems, a state indicates the system state at a time instant/interval .

**Visual definition**. According to Fig. 2, when the system is in state *p*, the state indicates the current state of the system at that specific moment.

**Logical definition of structure 3**. This structure shows that state *p* is true at time t. In other words, the system is in state *p* at time t (Relation 8).

$$\forall \forall \text{t} \left[ \mathbf{p}(\mathbf{t}, \mathbf{t}) \right] \tag{8}$$

**Structure 4**. Remaining in a state and change of the state. The system should stay in a state for a while and then the state should change.

**Visual definition**. When the system is in state L1, it should stay in this state at least for time unit d. After passing of the time and satisfaction of the condition, it would enter to state L2 (Fig. 4).

Fig. 4. Change of a state (C indicates clock)

**Logical definition of structure 4**. If the system is in state L1 after satisfaction of condition (c<=d) at time t, it would go to a new state (Relation 9).

$$\forall \mathbf{i} \; \forall \mathbf{t} [\mathbf{L}\_1(\mathbf{t}, \mathbf{t}) \land \neg \text{@(COND (c \lhd = d) \, , i)} = \mathbf{t}] \rightarrow \exists \mathbf{i} \; \mathbf{t} \; \left[\mathbf{L}\_1(\mathbf{t}, \mathbf{t}) \land \mathbf{t} \; \succeq \mathbf{t} \star \mathbf{q} \land \mathbf{q} \; \succeq \mathbf{s}\right] \tag{9}$$

Construction of Real-Time Oracle Using Timed Automata 139

method. The case study is an example of an automatic controller in which the *railway* gate opens and closes an intersection. The system contains three parts: *train*, *controller*, and *gate* (Fig.7). The connection between the train and controller is created by two *exit* and *approach* methods where the former denotes the train exits from the intersection and the latter denotes the train approaches the intersection. It is necessary that the train sends the approach signal less than two minutes before entering the intersection. This has been shown by a *protecting condition* X>2 along with event *in*. Table 1 shows explanation of states of train,

Controller

In addition, we know that the most delay between *exit* and *approach* signals is five minutes. This has been shown by the conditions X<=5 in transitions between states S1, S2 and S3. The gate is opened at T0 and closed at T2. The gate answers to *lower signal* by the open action in one to two minutes. The system clock is used to show the *constraints*. Initially the controller is in state U0 (*Idle)*. The controller responses to the gate by sending the *lower signal* when it receives the *approach signal* from the train and the controller responses to the gate by sending the raise signal when it receives the *exit signal* from the train. The response time of the controller for approach and exit signals are one minute and more than one minute

The system is in the safe state when the train is in the intersection, and the gate is low. In other words, if the train is in state S1, the gate should be in state T2. For example, consider paths originate from nodes S0, T0 and U0 and end with nodes S1, T0 and U1 and paths originate from nodes S1, T0 and U1 and end with nodes S2, T0 and U1 representing the event *approach* followed by event *in* immediately. However, this sequence cannot be true if we consider clocks. Now based on the former rules we resemble the previous model with real

U0: the controller is in standby state U1:The controller is in the lower signal state U2:The controller is in the raise signal state

gate and controller.

Fig. 7. Train, Gate and Controller states

S1:the train is approaching to the

Table 1. Explanation of Train, Controller and Gate states

respectively; these limitations have been shown by clock *z*.

S2: The train is in intersection S3: The train is leaving the

Gate T0: The gate is in upward state T1: The gate is coming down T2: The gate is in down state T3: The gate is going up

Train S0: the train is far from the intersection

intersection

intersection

time logic.

**Structure 5**. Transition from one state to several states by different events.

**Visual definition**. In Timed Automata, some state changes may depend on the condition holds on the transition, i.e., if the condition holds, the state change would happen. Some possible target states may be accessible from one source state when different conditions hold (Fig. 5).

Fig. 5. Change of states by occurrence of event

**Logical definition of structure 5**. Every time one of the events takes places and according to the occurred event, the system state changes (Relation 10).

$$\forall \mathbf{i}, \mathbf{t} \left[ \text{L}\_{\mathbf{d}}(\mathbf{t}, \mathbf{t}) \land \left( \text{COND}\_{1}, \mathbf{i} \right) = \mathbf{t} \right] \rightarrow \exists \mathbf{t}, \mathbf{q} \left[ \text{L}\_{\mathbf{d}}(\mathbf{t}, \mathbf{t}) \land \mathbf{t} \succeq \mathbf{t} \land \mathbf{q} \land \mathbf{q} \mathbf{0} \right] \lor \tag{10}$$
  $\forall \mathbf{i}, \mathbf{t} \left[ \text{L}\_{\mathbf{d}}(\mathbf{t}, \mathbf{t}) \land \left( \text{COND}\_{2}, \mathbf{i} \right) = \mathbf{t} \right] \rightarrow \exists \mathbf{t}, \mathbf{q} \left[ \text{L}\_{\mathbf{d}}(\mathbf{t}, \mathbf{t}) \land \mathbf{t} \succeq \mathbf{t} \land \mathbf{q} \land \mathbf{q} \mathbf{0} \right] \lor$   $\forall \mathbf{i}, \mathbf{t} \left[ \text{L}\_{\mathbf{d}}(\mathbf{t}, \mathbf{t}) \land \left( \text{COND}\_{n}, \mathbf{i} \right) = \mathbf{t} \right] \rightarrow \exists \mathbf{t}, \mathbf{q} \left[ \text{L}\_{\mathbf{n}}(\mathbf{t}, \mathbf{t}') \land \mathbf{t} \succeq \mathbf{t} \land \mathbf{q} \land \mathbf{q} \mathbf{0} \right] \lor$ 

**Structure 6**. To reach states of a system periodically. When we verify the system behavior, some states may be reached periodically.

**Visual definition**. In Timed Automata some sets of states and actions might be executed for several times. In such a situation, there will be iterations of some states for several times (Fig. 6).

**Logical definition of structure 6.** While the system is in state Ln and event *CONDn* occurs, the system will go to state L1; this leads to an iteration of states L1 and Ln. However, if the system is in state Ln and event *condi* take places, the system will go to state Ln+1 (Relation 11).

$$\forall \mathbf{i} \; \forall \mathbf{t} \; \left[ \mathbf{L}\_{\pi}(\mathbf{t}, \mathbf{t}) \land \oplus (\mathbf{C} \text{COND} \mathbf{n} \; , \mathbf{i}) = \mathbf{t} \right] \to \exists \; \mathbf{t} \; \mathbf{d} \; \left[ \mathbf{L}\_{\pi \ast \mathbf{l}}(\mathbf{t}\_{\text{l}} \mathbf{t}\_{\text{l}}) \land \mathbf{t}\_{\text{l}} \ge \mathbf{t} \; \neg \mathbf{d} \; \land \mathbf{d} \; \ge \mathbf{0} \right] \lor \tag{11}$$

∀i ∀t [Ln(t,t) ∧ @(CONDi , i) = t] → ∃ t2,d [L1(t2,t2) ∧ t2 ≥ t+d ∧ d ≥0]

Fig.6. Periodic change of states

#### **4.2 Case study**

In this section we propose a critical system and apply the first and second steps (specifying problem in Timed Automata and extracting the logical specification of the problem) of our 138 Real-Time Systems, Architecture, Scheduling, and Application

**Visual definition**. In Timed Automata, some state changes may depend on the condition holds on the transition, i.e., if the condition holds, the state change would happen. Some possible target states may be accessible from one source state when different conditions hold

**Logical definition of structure 5**. Every time one of the events takes places and according to

∀i, t [ L0(t,t) ∧ @(COND2 , i) = t] →∃ t',d [L2(t',t') ∧ t'≥ t+d ∧ d≥0] ∨

∀i, t [ L0(t,t) ∧ @(CONDn , i) = t] →∃ t',d [Ln(t',t') ∧ t'≥ t+d ∧ d≥0] **Structure 6**. To reach states of a system periodically. When we verify the system behavior,

**Visual definition**. In Timed Automata some sets of states and actions might be executed for several times. In such a situation, there will be iterations of some states for several times

**Logical definition of structure 6.** While the system is in state Ln and event *CONDn* occurs, the system will go to state L1; this leads to an iteration of states L1 and Ln. However, if the system is in state Ln and event *condi* take places, the system will go to state Ln+1 (Relation 11).

∀i ∀t [Ln(t,t) ∧ @(CONDi , i) = t] → ∃ t2,d [L1(t2,t2) ∧ t2 ≥ t+d ∧ d ≥0]

condn

L0 L1 Ln Ln+1

In this section we propose a critical system and apply the first and second steps (specifying problem in Timed Automata and extracting the logical specification of the problem) of our

∀i ∀t [Ln(t,t) ∧ @(CONDn , i) = t] → ∃ t1,d [Ln+1(t1,t1) ∧ t1 ≥ t+d ∧ d ≥0] ∨ (11)

condi

∀i, t [ L0(t,t) ∧ @(COND1 , i) = t] →∃ t',d [L1(t',t') ∧ t'≥ t+d ∧ d≥0] ∨ (10)

**Structure 5**. Transition from one state to several states by different events.

Fig. 5. Change of states by occurrence of event

some states may be reached periodically.

Fig.6. Periodic change of states

**4.2 Case study** 

the occurred event, the system state changes (Relation 10).

(Fig. 5).

(Fig. 6).

method. The case study is an example of an automatic controller in which the *railway* gate opens and closes an intersection. The system contains three parts: *train*, *controller*, and *gate* (Fig.7). The connection between the train and controller is created by two *exit* and *approach* methods where the former denotes the train exits from the intersection and the latter denotes the train approaches the intersection. It is necessary that the train sends the approach signal less than two minutes before entering the intersection. This has been shown by a *protecting condition* X>2 along with event *in*. Table 1 shows explanation of states of train, gate and controller.

Fig. 7. Train, Gate and Controller states


Table 1. Explanation of Train, Controller and Gate states

In addition, we know that the most delay between *exit* and *approach* signals is five minutes. This has been shown by the conditions X<=5 in transitions between states S1, S2 and S3. The gate is opened at T0 and closed at T2. The gate answers to *lower signal* by the open action in one to two minutes. The system clock is used to show the *constraints*. Initially the controller is in state U0 (*Idle)*. The controller responses to the gate by sending the *lower signal* when it receives the *approach signal* from the train and the controller responses to the gate by sending the raise signal when it receives the *exit signal* from the train. The response time of the controller for approach and exit signals are one minute and more than one minute respectively; these limitations have been shown by clock *z*.

The system is in the safe state when the train is in the intersection, and the gate is low. In other words, if the train is in state S1, the gate should be in state T2. For example, consider paths originate from nodes S0, T0 and U0 and end with nodes S1, T0 and U1 and paths originate from nodes S1, T0 and U1 and end with nodes S2, T0 and U1 representing the event *approach* followed by event *in* immediately. However, this sequence cannot be true if we consider clocks. Now based on the former rules we resemble the previous model with real time logic.

Construction of Real-Time Oracle Using Timed Automata 141

**Specification 7** [based on Logical definitions 1, 3 and 4]. Gate stays in state T1 as long as condition *y<=1* holds. In other words, if the gate is in state T1 at time *t*, it stays in the same

∀i ∀t [T1(t,t) ∧ @(COND (y<=1) , i) = t] → ∃t',d [ T1(t',t') ∧ t' ≥ t+d ∧ d≤1] **Specification 8** [based on Logical definitions 1 and 3]. Gate will be in state T2 at time *t'* if

∀i ∀t [T1(t,t) ∧ @(DOWN , i) = t] → ∃t',d [ T2(t',t') ∧ t' ≥ t+d ∧ d≥0] **Specification 9** [based on Logical definitions 1 and 3]. Train will be in state S2 at time *t* if at time *t* event *in* occurs and condition *X>2* holds. After that the train goes state S2 after time

∀i,j ∀t,t',d S1(t,t) ∧ @( IN , i) = t ∧ @(COND (x>2) , i) = t ∧ @(COND (x<=5) , i) = t] → ∃d,t'[S2(t',t') ∧ t' ≥ t+d ∧ d≥0] **Specification 10** [based on Logical definitions 1 and 3]. As long as condition *X<=5* holds and

∀i ∀t [ S2(t,t) ∧ @(COND (x<=5) , i) = t] → ∃t',d [S2(t',t') ∧ t' ≥ t+d ∧ d≥0] **Specification 11** [based on Logical definitions 1 and 3]. Train will be in state S3 at time *t'* if event OUT have occurred at time *t.* After that, train enters state S3 after time unit *d* if

∀i ∀t [ S2(t,t) ∧ @(COND (x<=5) , i) = t ∧ @(OUT , i)=t ] → ∃t',d [S3(t',t') ∧ t' ≥ t+d ∧ d≥0] **Specification 12** [based on Logical definitions 1 and 3]. Train will be in state S0 at time *t'* if

∀i ∀t [S3(t,t) ∧ @(SIGNAL (exit) , i) = t] → ∃t',d [S0(t',t') ∧ t' ≥ t+d ∧ d≥0] **Specification 13** [based on Logical definitions 2 and 3]. Controller will be in state U2 at time *t'* if it receives event *exit*. The event occurs due to exiting train from intersection at time *t*. Also if at the same time event *reset* of clock *z* occurs, train will enter the state U2 after time

∀i, j ∀t [U0(t,t) ∧ @( SIGNAL (exit) , i) = t ∧ @(↑RESET(z), j)= t ] →

∃t', q, d [U2(t',t') ∧ @(↓RESET(z) , q)= t' ∧ t' ≥ t+d ∧ d≥ε] **Specification 14** [based on Logical definitions 1 and 3]. Controller stays in state U2 as long as

∀i∀t [U2(t,t) ∧ @(COND (z<=1) , i) = t] → ∃t',d [ U2(t',t') ∧ t' ≥ t+d ∧ d≤1] **Specification 15** [based on Logical definitions 1 and 3]. Controller will be in state U0 after

∀i ∀t [ U2(t,t) ∧ @(SIGNAL (raise) , i) = t] → ∃t',d [U0(t',t') ∧ t' ≥ t+d ∧ d≥0]

event *exit* occurs at time *t*. After time unit *d*, train will be in state S0.

unit *d* and clock *z* is reset to zero at the same time.

time unit *d* when it receives signal *raise* at time *t*.

event DOWN occurs at time *t* and after time unit *d* the gate enters state T2.

state at time t' while condition *y<=1* holds.

unit *d* if condition *X<=5* holds at the same time.

train is in state S2, train stays in this state.

condition *X<=5* holds.

condition *Z<=1* holds.

**Specification 1** [based on Logical definition 3]. Initially, the train, the gate and the controller are in states S0, T0 and U0 respectively.

$$\forall t \left[ S\_0(t, t) \; \mathcal{A} \; \mathcal{U}\_0(t, t) \; \mathcal{A} T\_0(t, t) \right]$$

**Specification 2** [based on Logical definitions 2 and 3]. When the train is in state S0 and signal (event) *approach* occurs, after a while event ↑Reset(x) of clock *x* occurs. When event ↓Reset(x) occurs and clock *x* is reset by time *d*, the train is in the *approaching* state.

∀i ∀t [ S0(t,t) ∧ @(SIGNAL(approach), i) = t ]→ ∃ j, t', d [@(↑RESET(x), j)= t'∧ t'≥t +d ∧ d≥0] ∀i ∀t [@(↑RESET(x) , i)= t] → ∃j, t', d [@(↓RESET(x), j) = t' ∧ t'≥ t+d ∧ d ≥ε] ∀i ∀t [@(↓RESET(x), i)= t] → ∃ t', d [S1(t', t') ∧ t'≥ t+d ∧ d≥0]

**Specification 3** [based on Logical definitions 2 and 3]. When the train is approaching to the intersection, it is in state S1.

$$\forall \mathbf{t} \left[ \mathbf{S} \mathbf{t} (\mathbf{t}, \mathbf{t}) \; \right] \to \exists \mathbf{t}' \text{,} \mathbf{d} \left[ \mathbf{S} \mathbf{t} \left( \mathbf{t}', \mathbf{t}' \right) \land \mathbf{t} \succeq \mathbf{t} \star \mathbf{d} \land \mathbf{d} \ge \mathbf{0} \land \mathbf{d} \nleq \mathbf{5} \right]$$

**Specification 4** [based on Logical definitions 2 and 3]. When the controller is in state *standby* (denoted by state U0) and signal (event) approach occurs, the clock *z* is reset for making a transition from state U0 to state U1.

> ∀i ∀t [U0(t,t) ∧ @(SIGNAL(APPROACH), i) = t] → ∃j, t', d [@(↑RESET(z), j)= t' ∧ t'≥t +d ∧ d≥0] ∀i ∀t [@(↑RESET(z), i)= t] → ∃j, t', d [@(↓RESET(z), j) = t' ∧ t'>t+d ∧ d≥ε]

∀i ∀t [@(↓RESET(z), i)= t] → ∃ t' [U1(t',t') ∧ t'≥t+d ∧ d≥0]

**Specification 5** [based on Logical definitions 1 and 3]. As long as condition *z<=1* holds the controller stays in state U1.

$$\forall \mathbf{i}, \mathbf{t}\_1 \mathbf{t}\_2 \left[ \text{ U}\_1(\mathbf{t}\_1 \mathbf{t}\_1) \land \text{@(COND(z \lhd = 1), \mathbf{i} = \mathbf{t}\_2)} \right] \rightarrow \exists \mathbf{t}' \land \mathbf{d} \left[ \text{U}\_1(\mathbf{t}', \mathbf{t}') \land \text{t}' \textsf{\lhd \mathbf{t} + \mathbf{d} \land \text{d} \ge 0} \land \text{d} \le \mathbf{1} \right]$$

**Specification 6** [based on Logical definitions 2 and 3]. Assume that: (1) the controller and the gate are in states U1 and T0 at time *t* respectively, (2) at this time signal *lower* is generated and (3) event ↑Reset(y) occurs at time *t*' . Accordingly**,** the gate goes to state T1 and clock *y* is reset. If condition *z=1* holds at time *t*, the controller would enter the state at time *t'*.

∀i,j ∀t [U1(t, t ∧T0(t, t) ∧ @(SIGNAL(lower), i) = t ∧ (↑RESET(y), j)= t] → ∃t',q,d [T1(t', t') ∧ @(↓RESET(y), q)= t' ∧ t' ≥ t+d ∧ ≥ε] ∀i,j ∀t [ U1(t, t) ∧ T0(t,t) ∧ @( SIGNAL(lower), i) = t ∧ @(↑RESET(y) , j)= t ∧ @(COND (z=1), i) = t ] →

∃t',q,d [T1(t', t') ∧ U0(t', t') ∧ @(↓RESET(y), q)= t' ∧ t'≥t+d ∧ d≥ε].

140 Real-Time Systems, Architecture, Scheduling, and Application

**Specification 1** [based on Logical definition 3]. Initially, the train, the gate and the controller

**Specification 2** [based on Logical definitions 2 and 3]. When the train is in state S0 and signal (event) *approach* occurs, after a while event ↑Reset(x) of clock *x* occurs. When event

∀i ∀t [ S0(t,t) ∧ @(SIGNAL(approach), i) = t ]→ ∃ j, t', d [@(↑RESET(x), j)= t'∧ t'≥t +d ∧ d≥0]

∀i ∀t [@(↑RESET(x) , i)= t] → ∃j, t', d [@(↓RESET(x), j) = t' ∧ t'≥ t+d ∧ d ≥ε]

∀i ∀t [@(↓RESET(x), i)= t] → ∃ t', d [S1(t', t') ∧ t'≥ t+d ∧ d≥0] **Specification 3** [based on Logical definitions 2 and 3]. When the train is approaching to the

∀t [ S1(t,t) ] → ∃t',d [S1 (t',t') ∧ t'≥ t+d ∧ d≥0 ∧ d≤5] **Specification 4** [based on Logical definitions 2 and 3]. When the controller is in state *standby* (denoted by state U0) and signal (event) approach occurs, the clock *z* is reset for making a

∀i ∀t [U0(t,t) ∧ @(SIGNAL(APPROACH), i) = t] →

∃j, t', d [@(↑RESET(z), j)= t' ∧ t'≥t +d ∧ d≥0]

∀i ∀t [@(↑RESET(z), i)= t] → ∃j, t', d [@(↓RESET(z), j) = t' ∧ t'>t+d ∧ d≥ε]

∀i ∀t [@(↓RESET(z), i)= t] → ∃ t' [U1(t',t') ∧ t'≥t+d ∧ d≥0] **Specification 5** [based on Logical definitions 1 and 3]. As long as condition *z<=1* holds the

∀i,t1,t2 [ U1(t1,t1) ∧ @(COND(z<=1),i=t2) ] → ∃t',d [U1 (t',t') ∧ t'≥t+d ∧ d ≥ 0 ∧ d ≤ 1] **Specification 6** [based on Logical definitions 2 and 3]. Assume that: (1) the controller and the gate are in states U1 and T0 at time *t* respectively, (2) at this time signal *lower* is generated

∀i,j ∀t [U1(t, t ∧T0(t, t) ∧ @(SIGNAL(lower), i) = t ∧ (↑RESET(y), j)= t] →

∃t',q,d [T1(t', t') ∧ @(↓RESET(y), q)= t' ∧ t' ≥ t+d ∧ ≥ε]

∀i,j ∀t [ U1(t, t) ∧ T0(t,t) ∧ @( SIGNAL(lower), i) = t ∧ @(↑RESET(y) , j)= t ∧

@(COND (z=1), i) = t ] →

∃t',q,d [T1(t', t') ∧ U0(t', t') ∧ @(↓RESET(y), q)= t' ∧ t'≥t+d ∧ d≥ε].

reset. If condition *z=1* holds at time *t*, the controller would enter the state at time *t'*.

. Accordingly**,** the gate goes to state T1 and clock *y* is

∧ *U0(t,t)* ∧*T0(t,t)]* 

↓Reset(x) occurs and clock *x* is reset by time *d*, the train is in the *approaching* state.

∀*t [S0(t,t)* 

are in states S0, T0 and U0 respectively.

intersection, it is in state S1.

controller stays in state U1.

and (3) event ↑Reset(y) occurs at time *t*'

transition from state U0 to state U1.

**Specification 7** [based on Logical definitions 1, 3 and 4]. Gate stays in state T1 as long as condition *y<=1* holds. In other words, if the gate is in state T1 at time *t*, it stays in the same state at time t' while condition *y<=1* holds.

$$\text{Vi } \forall \mathbf{t} \left[ \mathbf{T}\_1(\mathbf{t}, \mathbf{t}) \land \oplus (\mathbf{C} \text{OND (y \prec= 1), i)} = \mathbf{t} \right] \rightarrow \exists \mathbf{t}', \mathbf{d} \left[ \mathbf{T}\_1(\mathbf{t}', \mathbf{t}) \land \mathbf{t}' \succeq \mathbf{t} \star \mathbf{d} \land \mathbf{d} \lhd \mathbf{1} \right].$$

**Specification 8** [based on Logical definitions 1 and 3]. Gate will be in state T2 at time *t'* if event DOWN occurs at time *t* and after time unit *d* the gate enters state T2.

∀i ∀t [T1(t,t) ∧ @(DOWN , i) = t] → ∃t',d [ T2(t',t') ∧ t' ≥ t+d ∧ d≥0]

**Specification 9** [based on Logical definitions 1 and 3]. Train will be in state S2 at time *t* if at time *t* event *in* occurs and condition *X>2* holds. After that the train goes state S2 after time unit *d* if condition *X<=5* holds at the same time.

$$\begin{aligned} \left( \forall \mathbf{i}, \mathbf{j} \,\forall \mathbf{t}, \mathbf{t'}, \mathbf{d} \,\mathbf{S}\_{\mathbf{l}}(\mathbf{t}, \mathbf{t}) \land \oplus (\mathbf{I} \,\mathbf{N} \,\mathbf{i} \,\mathbf{i}) = \mathbf{t} \land \oplus (\mathbf{COND} \,\left(\mathbf{x} \succeq \mathbf{2} \right) \,\mathbf{i}) = \mathbf{t} \land \oplus (\mathbf{COND} \,\left(\mathbf{x} \mathrel{\mathbf{x} = \mathbf{5}} \right) \,\mathbf{i}) = \mathbf{t} \right) \to \\ \exists \mathbf{d}, \mathbf{t'} [\mathbf{S}\_{\mathbf{2}}(\mathbf{t'}, \mathbf{t'}) \land \mathbf{t'} \succeq \mathbf{t} \land \mathbf{d} \land \mathbf{d} \,\mathbf{2} \,\mathbf{0}] \end{aligned} $$

**Specification 10** [based on Logical definitions 1 and 3]. As long as condition *X<=5* holds and train is in state S2, train stays in this state.

$$\forall \mathbf{i} \; \forall \mathbf{t} \; [\; \mathbb{S} \mathbf{j} \; \mathbf{t}, \mathbf{t} \; \mathbb{A} \; \mathbb{S} \; \mathbf{C} \; \mathrm{N} \; \mathbf{t} \; \mathbb{A} \; \exists \mathbf{t} \; \mathbf{t} \; \mathbf{t} \; \mathbb{A} \; \exists \mathbf{t} \; \mathbb{A} \; \mathbb{S} \; \mathbb{A} \; \mathbb{S} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A} \; \mathbb{A}$$

**Specification 11** [based on Logical definitions 1 and 3]. Train will be in state S3 at time *t'* if event OUT have occurred at time *t.* After that, train enters state S3 after time unit *d* if condition *X<=5* holds.

∀i ∀t [ S2(t,t) ∧ @(COND (x<=5) , i) = t ∧ @(OUT , i)=t ] → ∃t',d [S3(t',t') ∧ t' ≥ t+d ∧ d≥0]

**Specification 12** [based on Logical definitions 1 and 3]. Train will be in state S0 at time *t'* if event *exit* occurs at time *t*. After time unit *d*, train will be in state S0.

$$\forall \mathbf{i} \; \forall \mathbf{t} \; [\mathbb{S}\_{\overline{\mathbf{t}}}(\mathbf{t}, \mathbf{t}) \land \oplus (\text{SIGNAL (exit)}, \mathbf{i}) = \mathbf{t}] \rightarrow \exists \mathbf{t}', \mathbf{d} \; [\mathbb{S}\_{\overline{\mathbf{t}}}(\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \ge \mathbf{t} + \mathbf{d} \land \mathbf{d} \ge \mathbf{0}] \; \forall \mathbf{i} \; [\mathbf{t}', \mathbf{t}']$$

**Specification 13** [based on Logical definitions 2 and 3]. Controller will be in state U2 at time *t'* if it receives event *exit*. The event occurs due to exiting train from intersection at time *t*. Also if at the same time event *reset* of clock *z* occurs, train will enter the state U2 after time unit *d* and clock *z* is reset to zero at the same time.

$$\forall \mathbf{i}, \mathbf{j} \,\forall \mathbf{t} \,\left[ \mathbf{U} \mathbf{i} (\mathbf{t}, \mathbf{t}) \land \mathbb{Q} (\mathbf{S} \mathbf{I} \mathbf{G} \mathbf{N} \mathbf{A} \,\mathbf{I} \,\mathbf{z} \,\mathbf{i}) \right] \mathbf{i} \right] = \mathbf{t} \,\land\,\mathbb{Q} (\uparrow \mathbf{R} \mathbf{S} \mathbf{S} \mathbf{I} \mathbf{I} (\mathbf{z}) , \mathbf{j}) \mathbf{j} \succeq \mathbf{t} \,\,\mathbf{I} \to \mathbf{0}$$

∃t', q, d [U2(t',t') ∧ @(↓RESET(z) , q)= t' ∧ t' ≥ t+d ∧ d≥ε]

**Specification 14** [based on Logical definitions 1 and 3]. Controller stays in state U2 as long as condition *Z<=1* holds.

∀i∀t [U2(t,t) ∧ @(COND (z<=1) , i) = t] → ∃t',d [ U2(t',t') ∧ t' ≥ t+d ∧ d≤1]

**Specification 15** [based on Logical definitions 1 and 3]. Controller will be in state U0 after time unit *d* when it receives signal *raise* at time *t*.

$$\forall \mathbf{i} \; \forall \mathbf{t} \; \left[ \mathbf{U} \mathbf{\hat{z}} (\mathbf{t}, \mathbf{t}) \land \left( \mathbf{\hat{s}} \text{IGGNAL (raise)} \right) , \mathbf{i} \right] = \mathbf{t} \right] \rightarrow \exists \mathbf{t}' \; \mathbf{d} \; \left[ \mathbf{U} \mathbf{\hat{z}} (\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \ge \mathbf{t} \land \mathbf{d} \land \mathbf{q} \ge \mathbf{0} \right]$$

Construction of Real-Time Oracle Using Timed Automata 143

s0,u0,t0 x=y=z

> s1,u1,t0 x=z=0

s1,u0,t1 x=z=1,y=0

s2,u2,t2 z=0

> s3,u0,t3 y=0

s3,u0,t0 1=<y<=2

s1,u0,t2 x=z=2,y=1

s1,u2,t2 z=0

s2,u0,t3 y=0

s0,u0,t1 x=z,y=0

s3,u0,t2 2<x<=5

> s0,u0,t3 z=1

s0,u2,t2 z=0

Safe

Hazard

s: Train State u: Controller State t: Gate State

> s0,u0,t3 z<1

s0,u0,t0 1=<y<=2

s1,u0,t2 x=z<2,y<1

s2,u0,t2 x>2,y>=1

s3,u2,t2 z=0

s0,u1,t0 x=y=z

s1,u0,t3 y=0

s2,u0,t0 1=<y<=2

s1,u0,t0 1=<y<=2

Fig. 8. Reachability graph

**Specification 16** [based on Logical definitions 2 and 3]. Gate goes upward by receiving signal *raise* at time *t* and event ↑RESET(y) resets clock *y* at the same time. After time unit *d* if condition y<=2 holds, the gate enters state T3 at time *t'* and at the same time event ↓RESET(y) resets clock *y* to zero.

> ∀i,j,q ∀t,t',d [T2(t,t) ) ∧ @( SIGNAL(raise) , i) = t ∧ @(↑RESET(y) , j)= t ∧ @(COND (y<=2), q) = t ] →

∃t', m, d[T3(t',t') ∧ @(↓RESET(y) , m)= t' ∧ t' ≥ t+d ∧ d≥ε]

**Specification 17** [based on Logical definitions 1 and 3]. Gate will be in its first state, T0, at time *t'* if event *up* occurs at time *t* and at this time, events COND(y<=2) and COND (y>=1) occur. After time unit *d*, the gate enters state T0.

$$\forall \mathbf{i}, \mathbf{j}, \neq \; \forall \mathbf{t} \; \middle\[ \; \mathbf{T} \; \mathbf{(t}, \mathbf{t}) \land \oplus (\; \mathbf{UP}, \mathbf{i}) = \mathbf{t} \land \oplus (\; \mathbf{COND} \; \mathbf{(y>=1)}, \mathbf{j}) = \mathbf{t} \land \oplus (\; \mathbf{COND} \; \mathbf{(y<=2)}, \mathbf{q}) = \mathbf{t} \right] \rightarrow$$
 
$$\exists \mathbf{t}', \mathbf{d} \; \left[ \mathbf{T}\_{\mathbf{0}} (\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \succeq \mathbf{t} \land \mathbf{d} \land \mathbf{d} \\$ \mathbf{0} \right]$$

#### **4.3 Extracting reachability graph**

In the previous section, we stated textual specification of the Timed Automata of road and railway intersection in RTL. Having extracted reachability graph from Timed Automata, we use RTL to verify those situations in which the system enters *unsafe* states. Fig. 8 shows the reachability graph of road and railway intersection system. The *gray* parts of the graph are *unsafe* states that the system should never enter. To verify the system behavior against the unsafe states, we aim to construct verification rules (constraints). These rules are intended to monitor change of system states against the unsafe states. These rules are based on the structures specified in Section 4.

**Verification rule 1**. When the train is approaching the intersection, the gate should get lower (state T1).

$$\forall \mathbf{t} \; [\mathbf{S}\_1(\mathbf{t}, \mathbf{t})] \to \exists \mathbf{t}', \mathbf{d} \; [\mathbf{T}\_1(\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \ge \mathbf{t} \star \mathbf{d} \land \mathbf{d} \ge \mathbf{0}].$$

**Verification rule 2**. When the train is approaching the intersection, the gate should not be up or should not move up (states T0 and T1); otherwise it is an unsafe situation (state H3 in Fig. 8).

$$\forall \mathbf{t} \,\mathrm{'F\_1(t,t)} \,\mathrm{\underline{\cdot}} \vdash \exists \mathbf{t}', \mathbf{q} \,\mathrm{[}\neg \Gamma\_1(\mathbf{t}', \mathbf{t}') \land \neg \Gamma\_2(\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \geq \mathbf{t} \,\neg \mathbf{q} \,\mathrm{\underline{\cdot}}\,\mathrm{\underline{\cdot}}\,\mathrm{]}$$

**Verification rule 3**. When train is in intersection (state S2), the gate should be down (state T2); otherwise it is an unsafe situation (state H4 in Fig. 8).

$$\forall \mathbf{t} \; [\mathbf{S}\_2(\mathbf{t}, \mathbf{t})] \to \exists \mathbf{t}', \mathbf{d} \; [\mathbf{T}\_2(\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \ge \mathbf{t} + \mathbf{d} \land \mathbf{d} \ge \mathbf{0}]$$

**Verification rule 4**. When train is in intersection (state S2), the gate should not be up or should not move down; otherwise it is an unsafe situation (states H4 and H5 in Fig. 8).

$$\forall t \left[ \mathsf{S}\_2(\mathsf{t}, \mathsf{t}) \left[ \neg \exists \mathsf{t}', \mathsf{d} \left[ (\neg \mathsf{T}\_0(\mathsf{t}', \mathsf{t}') \lor \neg \mathsf{T}\_1(\mathsf{t}', \mathsf{t}') \right) \land \mathsf{t}' \geq \mathsf{t} \mathsf{d} \land \mathsf{d} \geq 0 \right] \right]$$

142 Real-Time Systems, Architecture, Scheduling, and Application

**Specification 16** [based on Logical definitions 2 and 3]. Gate goes upward by receiving signal *raise* at time *t* and event ↑RESET(y) resets clock *y* at the same time. After time unit *d* if condition y<=2 holds, the gate enters state T3 at time *t'* and at the same time event

∀i,j,q ∀t,t',d [T2(t,t) ) ∧ @( SIGNAL(raise) , i) = t ∧ @(↑RESET(y) , j)= t ∧

@(COND (y<=2), q) = t ] →

∃t', m, d[T3(t',t') ∧ @(↓RESET(y) , m)= t' ∧ t' ≥ t+d ∧ d≥ε] **Specification 17** [based on Logical definitions 1 and 3]. Gate will be in its first state, T0, at time *t'* if event *up* occurs at time *t* and at this time, events COND(y<=2) and COND (y>=1)

∀i, j, q ∀t [ T3(t,t) ∧ @( UP , i) = t ∧ @(COND (y>=1) , j) = t ∧ @(COND (y<=2) , q) = t] →

∃t', d [T0(t',t') ∧ t' ≥ t+d ∧ d≥0]

In the previous section, we stated textual specification of the Timed Automata of road and railway intersection in RTL. Having extracted reachability graph from Timed Automata, we use RTL to verify those situations in which the system enters *unsafe* states. Fig. 8 shows the reachability graph of road and railway intersection system. The *gray* parts of the graph are *unsafe* states that the system should never enter. To verify the system behavior against the unsafe states, we aim to construct verification rules (constraints). These rules are intended to monitor change of system states against the unsafe states. These rules are based on the

**Verification rule 1**. When the train is approaching the intersection, the gate should get

∀t [S1(t,t)] → ∃t',d [T1(t',t') ∧ t' ≥ t+d ∧ d≥0] **Verification rule 2**. When the train is approaching the intersection, the gate should not be up or should not move up (states T0 and T1); otherwise it is an unsafe situation (state H3 in

∀t [S1(t,t) ]→ ∃t',d [¬T1(t',t') ∧ ¬T3(t',t') ∧ t' ≥ t+d ∧ d≥0] **Verification rule 3**. When train is in intersection (state S2), the gate should be down (state

∀t [S2(t,t)] → ∃t',d [T2(t',t') ∧ t' ≥ t+d ∧ d≥0] **Verification rule 4**. When train is in intersection (state S2), the gate should not be up or should not move down; otherwise it is an unsafe situation (states H4 and H5 in Fig. 8).

∀t [S2(t,t) ]→∃t',d [(¬T0(t',t') ∨ ¬T1(t',t') ) ∧ t' ≥ t+d ∧ d≥0]

↓RESET(y) resets clock *y* to zero.

occur. After time unit *d*, the gate enters state T0.

**4.3 Extracting reachability graph** 

structures specified in Section 4.

T2); otherwise it is an unsafe situation (state H4 in Fig. 8).

lower (state T1).

Fig. 8).

Fig. 8. Reachability graph

Construction of Real-Time Oracle Using Timed Automata 145

1997, Douglass, 1999, Jalili & MirzaAghaei, 2007) exploiting event-based approach for realtime systems, used real-time logic (RTL) for high-level specification of system requirements; so, they were capable of specifying real-time requirements, particularly ordering of events.

Alur R. & Dill D.L. (1994). A theory of timed automata, *Theoretical Computer Science, Elsevier*,

Alur R. & Dill D.L. (1996). Automata-theoretic verification of real-time systems, *Formal* 

Barringer H. et al. (2004). Rule-Based Runtime Verification, *Proceedings of the 5th International* 

Bellini P. et al *(* 2000). Temporal logics for real-time system specification, *ACM Computing* 

Chen, F. & Rosu, G. (2005). Java-MOP: A Monitoring Oriented Programming Environment

d'Amiron, M. & Havelund, K. (2005). Event-Based Runtime Verification of Java Programs,

Douglass, B.P. (1999). Doing Hard Time, Developing Real-Time Systems with UML, Objects,

Jahanian-a F. et al (1988). A Graph-theoretic approach for timing analysis in real time logic ,

Jahanian-b F. et al (1988). Formal specification of real-time systems, Technical Report,

Jahanian F. (1994). Modechart: a specification language for real-time systems, *IEEE Trans. on* 

Jalili S. & MirzaAghaei, M. (2007). RVERL: Run-time Verification of Real-time and Reactive

Li, C. & Dang, Z. (2006). Decompositional Algorithms for Safety Verification and Testing of

Mok, A.K. & Liu, G. (1997). Efficient Run-time Monitoring of Timing Constraints,

Paneka S. et al (2006). Scheduling and planning with timed automata, *Proceedings of 16th*

*Runtime Verification*, *FATES 2006 & RV 2006*, Springer, Vol. 4262.

Programs using Event-based Real-Time Logic Approach, *Proceedings of the 5th International Conference on Software Engineering Research, Management & Applications* 

Aspect-Oriented Systems, *Proceedings of Formal Approaches to Software Testing and* 

*Proceedings of the IEEE Real-Time Technology and Applications Symposium*, pp. 252-

*European Symposium on Computer Aided Process Engineering and 9th International Symposium on Process Systems Engineering*, W. Marquardt, C. Pantelides (Editors),

*Methods for Real-Time Computing*, *Trends in Software Series*, Wiley & Sons, pp. 55-

*Conference on Verification, Model Checking and Abstract Interpretation (VMCAI'04),*

for Java, *Proceedings of the 11th International Conference on Tools and Algorithms for the* 

*Proceedings of the 5th Workshop of ICSE (International Conference on Software* 

**6. References** 

82.

262.

Elsevier.

Vol. 126, No. 2, pp. 183-235.

LNCS2937, Springer, pp. 44-57.

*Surveys*, Vol. 32, No. 1, pp. 12-42.

*Construction and Analysis of Systems*, pp. 546-550.

*Engineering) on Dynamic Analysis*, pp. 1-7.

Framework and Patterns, Addison-Wesley.

*University of Texas at Austin Austin*, *USA*.

*Proceedings of IEEE Real-Time Systems Symposium*.

*Software Engineering*, Vol. 20 , No.12, pp. 933-947.

*(SERA 2007)*, IEEE Computer Society, pp. 550-557.

**Verification rule 5**. When train has not left the intersection (state S3), the gate should be down; otherwise it is an unsafe situation (state H5 in Fig. 8).

$$\forall \mathbf{t} \; [\mathbf{S}\_2(\mathbf{t}, \mathbf{t})] \to \exists \mathbf{t}', \mathbf{d} \; [\mathbf{T}\mathbf{2}(\mathbf{t}', \mathbf{t}') \land \mathbf{t}' \ge \mathbf{t} + \mathbf{d} \land \mathbf{d} \ge \mathbf{0}]$$

**Verification rule 6**. When train has not left the intersection (state S3), the gate should not up or should not move up; otherwise it is an unsafe situation (state H5 in Fig. 8).

$$\forall t \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}} \,\mathrm{d}^{\mathrm{d}}$$

**Verification rule 7**. When train is leaving the intersection, the gate should go up; otherwise it is an unsafe situation (state H2 in Fig. 8).

$$\forall \mathbf{t} \left[ \mathbf{S}\_0(\mathbf{t}, \mathbf{t}) \land \mathbf{U}\_0(\mathbf{t}, \mathbf{t}) \right] \to \exists \mathbf{t}' \mathbf{q} \left[ \mathbf{T}\_3(\mathbf{t}', \mathbf{t}) \lor \mathbf{t} \ge \mathbf{t} + \mathbf{q} \land \mathbf{q} \ge 0 \right]$$

**Verification rule 8**. When train is not in intersection, the gate should not be down or should not move down; otherwise it is an unsafe situation (states H1 and H2 in Fig. 8).

$$\forall \mathbf{t} \, [\mathbf{S}\_0(\mathbf{t}, \mathbf{t}) \; ] \rightarrow \exists \mathbf{t}', \mathbf{d} [(\neg \mathbf{T}\_1(\mathbf{t}', \mathbf{t}') \lor \neg \mathbf{T}\_2(\mathbf{t}', \mathbf{t}')) \land \mathbf{t}' \rhd \mathbf{t} \, \mathbf{d} \, \land \mathbf{d} \\$ 0] \; ]$$

### **5. Conclusions and related work**

In this paper, we dealt with producing verification rules for verification of real-time systems systematically. As a matter of fact, our contribution to the rule production had three aspects. The first one was determination and representation of basic constructions of Timed Automata that were susceptible to making basic verification rules. The second one was producing rules systematically, where it was achieved through reachability graph. The reachability graph as a bridge helped us to extract safety rules from visual specifications. The third aspect was mapping the safety properties obtained from the reachability graph into RTL propositions forming the verification rules. Finally, to show effectiveness of our approach we applied it to a real-time system. In the following, we state the related work.

Jahanian and Mok specified high-level requirements by the Modechart visual and specific language and mapped them to a constraint graph (Chen & Rosu, 2005) where the graph was used by a monitor in order to verify software behavior.

Deriving monitors from requirements has been considered by some researchers. The *Eagle* method used the *Eagle logic* to specify requirements and synthesized a rule based monitor (Barringer et al, 2004). It extended Mu Calculus to support past and future time linear logic and real-time one. *Eagle* exploiting a state-based approach (d'Amiron & Havelund, 2005) was extended by the HAWK logic (d'Amiron & Havelund, 2005). To support event-based specifications, the HAWK language, used to specify both high-level specifications and lowlevel run-time states, has included low-level programming definitions to verify java programs.

(Mok & Liu, 1997, Chen & Rosu, 2005) used real-time logic (RTL) for the requirements specification of real-time system. Li and Dang presented algorithms to combine automata with *black-box testing* in order to verify safety properties (Li, & Dang, 2006). (Mok & Liu, 1997, Douglass, 1999, Jalili & MirzaAghaei, 2007) exploiting event-based approach for realtime systems, used real-time logic (RTL) for high-level specification of system requirements; so, they were capable of specifying real-time requirements, particularly ordering of events.
