**6. References**

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

**Verification rule 5**. When train has not left the intersection (state S3), the gate should be

∀t [S3(t,t)] → ∃t',d [T2(t',t') ∧ t' ≥ t+d ∧ d≥0] **Verification rule 6**. When train has not left the intersection (state S3), the gate should not up

∀t [S3(t,t) ] → ∃t',d [(¬T0(t',t') ∨ ¬T1(t',t') ∨ ¬T3(t',t') ) ∧ t' ≥ t+d ∧ d≥0] **Verification rule 7**. When train is leaving the intersection, the gate should go up; otherwise

∀t [S0(t,t) ∧ U0(t,t) ] → ∃t',d [T3(t',t') ∧ t' ≥ t+d ∧ d≥0] **Verification rule 8**. When train is not in intersection, the gate should not be down or should

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

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

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

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

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

or should not move up; otherwise it is an unsafe situation (state H5 in Fig. 8).

not move down; otherwise it is an unsafe situation (states H1 and H2 in Fig. 8).

down; otherwise it is an unsafe situation (state H5 in Fig. 8).

it is an unsafe situation (state H2 in Fig. 8).

**5. Conclusions and related work** 

used by a monitor in order to verify software behavior.

state the related work.

programs.


**Scheduling** 

Penczek W. & Polrola A. (2006). Advances in verification of timed petri-nets and timed automata, *Studies in Computational Intelligence*, Springer. **Part 3**  automata, *Studies in Computational Intelligence*, Springer. **Part 3** 

**Scheduling** 

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

Penczek W. & Polrola A. (2006). Advances in verification of timed petri-nets and timed

**0**

**7**

*Italy*

**Handling Overload Conditions**

This chapter deals with the problem of handling overload conditions, that is, those critical situations in which the computational demand requested by the application exceeds the processor capacity (Buttazzo, 2011). If not properly handled, an overload can cause an abrupt performance degradation, or even a system crash. Therefore, a real-time system should be designed to anticipate and tolerate unexpected overload situations through specific kernel

Overload conditions can occur for different causes, including bad system design, simultaneous arrival of events, operating system exceptions, malfunctioning of input devices,

In the following, we consider a set of *n* periodic or sporadic tasks, Γ = {*τ*1,..., *τn*}, each characterized by a worst-case execution time (WCET) *Ci*, a relative deadline *Di*, and a period (or minimum inter-arrival time) *Ti*. Each task *τ<sup>i</sup>* is initially activated at time Φ*<sup>i</sup>* (denoted as the task phase) and generates an infinite sequence of jobs *τi*,*<sup>k</sup>* (*k* = 1, 2, . . .). If a task *τ<sup>i</sup>* is periodic, a generic job *τi*,*<sup>k</sup>* is regularly activated at time *ri*,*<sup>k</sup>* = Φ*<sup>i</sup>* + (*k* − 1)*Ti*. In general, the activation

*ri*,*k*+<sup>1</sup> = *ri*,*<sup>k</sup>* + *Ti* if *τ<sup>i</sup>* is periodic *ri*,*k*+<sup>1</sup> ≥ *ri*,*<sup>k</sup>* + *Ti* if *τ<sup>i</sup>* is sporadic *ri*,*k*+<sup>1</sup> > *ri*,*<sup>k</sup>* if *τ<sup>i</sup>* is aperiodic. Also, each job *τi*,*<sup>k</sup>* is characterized by an absolute deadline *di*,*<sup>k</sup>* = *ri*,*<sup>k</sup>* + *Di*. For a set of periodic tasks, the *hyperperiod H* denotes the minimum interval of time after which the schedule repeats itself. For a set of periodic tasks synchronously activated at time *t* = 0 (Φ*<sup>i</sup>* = 0, for all *i*), the hyperperiod is equal to the least common multiple of all the periods, that is

In a real-time system, the computational load depends on the temporal characteristics of the executing activities. For example, for a set of *n* periodic tasks, the system load is equivalent to

> *n* ∑ *i*=1

*Ci Ti*

*U* =

and unpredicted variations of the environmental conditions.

⎧ ⎨ ⎩

the processor utilization factor (Liu & Layland, 1973):

**1. Introduction**

mechanisms.

time of job *τi*,*k*+<sup>1</sup> is:

*H* = lcm(*T*1,..., *Tn*).

**in Real-Time Systems**

. (1)

Giorgio C. Buttazzo *Scuola Superiore Sant'Anna*
