Construction of Real-Time Oracle Using Timed Automata

Verification of real time software is facing two problems: (1) how we should manage to produce verification rules and (2) how we should apply the rules to specify the problem. In this chapter we provide a method by which we get down to these two problems. In the first step, we specify real time software using Timed Automata and then we state it in RTL, real time logic, propositions. Timed Automata address modeling systems in time (Alure & Dill, 1996). In the second step, we obtain the safety constraints from reachability graph of Timed Automata of the problem specification and after that we state it in real time logic propositions. These propositions showing safety constraints are used for verification of the propositions, i.e. the results of the specification obtained in the first step. To show the effectiveness of our method, we set forth it for the RCC (Rail Road Crossing Control) real time system.


Introduction
Verification of real time software is facing two problems: (1) how we should manage to produce verification rules and (2) how we should apply the rules to specify the problem. In this chapter we provide a method by which we get down to these two problems. In the first step, we specify real time software using Timed Automata and then we state it in RTL, real time logic, propositions. Timed Automata address modeling systems in time (Alure & Dill, 1996). In the second step, we obtain the safety constraints from reachability graph of Timed Automata of the problem specification and after that we state it in real time logic propositions. These propositions showing safety constraints are used for verification of the propositions, i.e. the results of the specification obtained in the first step. To show the effectiveness of our method, we set forth it for the RCC (Rail Road Crossing Control) real time system. Software verification is an important process in constructing software and a main factor for obtaining safety from the quality of software. For verification of software we should deal with its verification against the expected behavior. The expected behavior is safe characteristics or prepositions that the software must always agree with. For this purpose, there are three main approaches: (1) static verification, (2) software testing and (3) run-time verification. Meanwhile one of the important and key approaches, essentially used for mission and safety critical systems, is the run-time verification; the existence of the problems in the first and second approaches is the reason of using run-time verification. For example, we can indicate the disability of the first method in proving the complicated and large specifications. Another instance is rapidly increasing the number of states (called state explosion) in the model checking method, which is a static verification one.
Because Timed Automata are methods based on time and event, they are suitable for describing the behavior of real time systems and because Timed Automata are visual methods, their understanding is easy. But they have limitations for specification of some statuses and also they cannot specify some conditions very well. Therefore, we need especial methods for analysis and verification of Timed Automata behavior that increase safety in these systems and decrease the amount of the faults.
There are different ways to verification of Timed Automata behavior. One of these ways is using reachability graph; however an especial method should be chosen to cover the 130 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 et al, 2006).
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 constraints of the system would by more.
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 unsafe states.

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, S 0 , 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 (S 0 ⊂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. 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)

Networks of timed automata
In this section, we define networks of Timed Automata, consisting of several Timed Automata running in parallel and communicating with each other.
Each element e of E is denoted by a,cc,X ll ' ⎯⎯⎯ → 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 lL ∈ 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 X C 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 definitions 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).
• For 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 , satisfies the invariant l' .

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: 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, 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 i th occurrence of event e where e can be a starting or external event (Jahanian-a et al, 1998).

Example:
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:

The RTL Language
In this section, we introduce the RTL language; the following notations are used in RTL formulae: • true and false The time terms in RTL consist of constants, variables and if t 1 and t 2 are time terms, then t 1 + t 2 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.

www.intechopen.com
Real-Time Systems, Architecture, Scheduling, and Application

134
The propositions in RTL consist of truth symbols, true and false and: if t 1 and t 2 are time terms and ρ is an inequality/equality predicate, then t 1 ρ t 2 is a proposition if i and j are occurrence terms and ρ is an inequality/equality predicate symbol, then i ρ j is a proposition if i is an occurrence term, t is a time term and e is an event constant, then R (e, i, t ) is a proposition.
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, 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: 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 i th occurrence of event (S:=F) is at time t. This means that i th 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).  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 E t and E f denote the transition events making S true and false, respectively. Informally: -"[x " denotes that E t occurs at time x, -"(x " denotes that E t occurs before or at time x, -"<x" denotes that E t occurs before time x, -" y]" denotes that E f occurs at time y, -" y)" denotes that E f does not occur before time y, -" y>" denotes that E f does not occur before or at time y. . The other intervals are defined similarly (Jahanian-b , 1998).

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 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

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). 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).
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). Visual definition. When the system is in state L 1 , 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 L 2 (Fig. 4).

Fig. 4. Change of a state (C indicates clock)
Logical definition of structure 4. If the system is in state L 1 after satisfaction of condition (c<=d) at time t, it would go to a new state (Relation 9). 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).
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 L n and event COND n occurs, the system will go to state L 1 ; this leads to an iteration of states L 1 and L n . However, if the system is in state L n and event condi take places, the system will go to state L n+1 (Relation 11).

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 L 0 L 1 L n+1 L n cond n cond i

www.intechopen.com
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, gate and 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 S 1 , S 2 and S3. The gate is opened at T 0 and closed at T 2 . 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 U 0 (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 S 1 , the gate should be in state T 2 . For example, consider paths originate from nodes S 0 , T 0 and U 0 and end with nodes S 1 , T 0 and U 1 and paths originate from nodes S 1 , T 0 and U 1 and end with nodes S 2 , T 0 and U 1 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.
Specification 1 [based on Logical definition 3]. Initially, the train, the gate and the controller are in states S 0 , T 0 and U 0 respectively.
Specification 2 [based on Logical definitions 2 and 3]. When the train is in state S 0 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.
Specification 3 [based on Logical definitions 2 and 3]. When the train is approaching to the intersection, it is in state S 1 .
Specification 4 [based on Logical definitions 2 and 3]. When the controller is in state standby (denoted by state U 0 ) and signal (event) approach occurs, the clock z is reset for making a transition from state U 0 to state U 1 .
Specification 5 [based on Logical definitions 1 and 3]. As long as condition z<=1 holds the controller stays in state U 1 .
Specification 6 [based on Logical definitions 2 and 3]. Assume that: (1) the controller and the gate are in states U 1 and T 0 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 T 1 and clock y is reset. If condition z=1 holds at time t, the controller would enter the state at time t'.
Specification 7 [based on Logical definitions 1, 3 and 4]. Gate stays in state T 1 as long as condition y<=1 holds. In other words, if the gate is in state T 1 at time t, it stays in the same state at time t' while condition y<=1 holds.
Specification 8 [based on Logical definitions 1 and 3]. Gate will be in state T 2 at time t' if event DOWN occurs at time t and after time unit d the gate enters state T 2 .
Specification 9 [based on Logical definitions 1 and 3]. Train will be in state S 2 at time t if at time t event in occurs and condition X>2 holds. After that the train goes state S 2 after time unit d if condition X<=5 holds at the same time.
Specification 10 [based on Logical definitions 1 and 3]. As long as condition X<=5 holds and train is in state S 2 , train stays in this state. Also if at the same time event reset of clock z occurs, train will enter the state U 2 after time unit d and clock z is reset to zero at the same time.

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 T 1 ).
Verification rule 2. When the train is approaching the intersection, the gate should not be up or should not move up (states T 0 and T 1 ); otherwise it is an unsafe situation (state H 3 in Fig. 8).
Verification rule 3. When train is in intersection (state S 2 ), the gate should be down (state T 2 ); otherwise it is an unsafe situation (state H 4 in Fig. 8).
∀t [S 2 (t,t)] ∃t',d [T 2 (t',t') ∧ t' ≥ t+d ∧ d≥0] Verification rule 4. When train is in intersection (state S 2 ), the gate should not be up or should not move down; otherwise it is an unsafe situation (states H 4 and H 5 in Fig. 8).
∀t [S 3 (t,t)] ∃t',d [T2(t',t') ∧ t' ≥ t+d ∧ d≥0] Verification rule 6. When train has not left the intersection (state S 3 ), the gate should not up or should not move up; otherwise it is an unsafe situation (state H 5 in Fig. 8).
∀t [S 0 (t,t) ∧ U 0 (t,t) ] ∃t',d [T 3 (t',t') ∧ t' ≥ t+d ∧ d≥0] 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 H 1 and H 2 in Fig. 8).

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.