jamris 2009 vol 3 no 1

Editor-in-Chief

Co-Editors:

Janusz Kacprzyk

Dimitar Filev

Kaoru Hirota

Witold Pedrycz

Roman Szewczyk

(Systems Research Institute, Polish Academy of Sciences , Poland)

(Research & Advanced Engineering, Ford Motor Company, USA)

(Interdisciplinary Graduate School of Science and Engineering,

Tokyo Institute of Technology, Japan)

(ECERF, University of Alberta, Canada)

(PIAP, Warsaw University of Technology )

; PIAP

, Poland

(Polish Academy of Sciences; PIAP, Poland)

Editorial Office:

Al. Jerozolimskie 202, 02-486 Warsaw, POLANDTel. +48-22-8740109,

Chairman:

Industrial Research Institute for Automationand Measurements PIAP

Janusz KacprzykPlamen AngelovZenn BienAdam BorkowskiWolfgang BorutzkyOscar CastilloChin Chen ChangJorge Manuel Miranda DiasBogdan GabryśJan JabłkowskiStanisław KaczanowskiTadeusz KaczorekMarian P. KaźmierkowskiJózef KorbiczKrzysztof KozłowskiEckart KramerAndrew KusiakMark LastAnthony MaciejewskiKrzysztof Malinowski

[email protected]

Editorial Board:

(Lancaster University, UK)

(Korea Advanced Institute of Science and Technology, Korea)

(Polish Academy of Sciences, Poland)

(Fachhochschule Bonn-Rhein-Sieg, Germany)

(Tijuana Institute of Technology, Mexico)

(Feng Chia University, Taiwan)

(University of Coimbra, Portugal)

(Bournemouth University, UK)

(PIAP, Poland)

(PIAP, Poland)

(Warsaw University of Technology, Poland)


(University of Zielona Góra, Poland)

(Poznań University of Technology, Poland)

(Fachhochschule Eberswalde, Germany)

(University of Iowa, USA)

(Ben–Gurion University of the Negev, Israel)

(Colorado State University, USA)


Executive Editor:

Associate Editors:

Webmaster:

Proofreading:

Copyright and reprint permissionsExecutive Editor

Anna Ładan

Mariusz AndrzejczakKatarzyna Rzeplińska-Rykała

Tomasz Kobyliński

Urszula Wiączek

Andrzej MasłowskiTadeusz MissalaFazel NaghdyZbigniew NahorskiAntoni NiederlińskiWitold PedryczDuc Truong PhamLech PolkowskiAlain PruskiLeszek RutkowskiKlaus SchillingRyszard Tadeusiewicz

Stanisław TarasiewiczPiotr TatjewskiWładysław TorbiczLeszek TrybusRené WamkeueJanusz ZalewskiMarek ZarembaTeresa Zielińska

[email protected]

[email protected]

(PIAP, Poland)

(PIAP, Poland)

(PIAP, Poland)

(PIAP, Poland)

(University of Wollongong, Australia)

(Polish Academy of Science, Poland)

(Silesian University of Technology, Poland)

(University of Alberta, Canada)

(Cardiff University, UK)

(Polish-Japanese Institute of Information Technology, Poland)

(University of Metz, France)

(Częstochowa University of Technology, Poland)

(Julius-Maximilians-University Würzburg, Germany)

(AGH University of Science and Technology

in Kraków, Poland)

(University of Laval, Canada)


(Polish Academy of Sciences, Poland)

(Rzeszów University of Technology, Poland)

(University of Québec, Canada)

(Florida Gulf Coast University, USA)

(University of Québec, Canada)


JOURNAL of AUTOMATION, MOBILE ROBOTICS& INTELLIGENT SYSTEMS

All rights reserved © 1

Publisher:Industrial Research Institute for Automation and Measurements PIAP

If in doubt about the proper edition of contributions, please contact the Executive Editor. , excluding advertisements and descriptions of products.The Editor does not take the responsibility for contents of advertisements, inserts etc. The Editor reserves the right to make relevant revisions, abbreviations

and adjustments to the articles.

Articles are reviewed

2

JOURNAL of AUTOMATION, MOBILE ROBOTICS& INTELLIGENT SYSTEMSVOLUME 3, N° 1, 2009

CONTENTS

REGULAR PAPERS

EDITORIAL

T. Kaczorek

T. Kaczorek, M. Busłowicz

M. Busłowicz

W. Grega, A. J. Kornecki, J. Zalewski

M. Leuchter, S. Tyszberowicz, Y. A. Feldman

O. Tveretina

SPECIAL ISSUE SECTIONDependability and Safety of Real-Time

Computer SystemsEditors: Wojciech Grega, Andrew J. Kornecki,

Janusz Zalewski

Towards the safety verification of real-time systemswith the coq proof assistant

Improving dependability of automation for freeelectron laser FLASHB. Kosęda, T. Szmuc, W. Cichalewski

Reachability of fractional positive continuous-timelinear systems

Pointwise completeness and pointwise degeneracyof linear continuous-time fractional order systems

Stability analysis of linear continuous-time fractionalsystems of commensurate order

Reusing Verilog Designs in the Synchronous LanguageEsterel

T. Letia, S. Barbu, F. Dinga

S. Lu, W. A. Halang

A. J. Kornecki, T. B. Hilburn, W. Grega, M. Sveda,J-M. Thiriet

Using pre-emption for dependable urban vehicletraffic

Incorporating fault tolerance into component-basedarchitectures for embedded systems

Task jitter measurement under RTLinux operatingsystem

ILERT - international learning environment for real-time software-intensive control systems

Fault sensitivity of explicit DMC and GPC algorithms

Speed analysis of a digital controller in time criticalapplications

P. Gawkowski, M. Ławryńczuk, P. Marusak, J. Sosnowski,P. Tatjewski

P. Piątek, W. Grega

DEPARTMENTS

IN THE SPOTLIGHT

EVENTS

3

52

72

74

57

62

66

8

12

20

23

30

33

46

40

Abstract:

1. IntroductionIn positive systems inputs, state variables and out-

puts take only non-negative values. Examples of positivesystems are industrial processes involving chemicalreactors, heat exchangers and distillation columns, sto-rage systems, compartmental systems, water and atmo-spheric pollution models. A variety of models havingpositive linear systems behaviour can be found in engi-neering, management science, economics, social scien-ces, biology and medicine, etc.

Positive linear systems are defined on cones and noton linear spaces. Therefore, the theory of positive sys-tems is more complicated and less advanced. An overviewof state of the art in positive systems is given in themonographs [2, 5]. An extension of positive systems arethe cone systems [6, 9].

The notion of cone systems was introduced in [6].Roughly speaking cone system is a system obtained frompositive one by substitution of the positive orthants ofstates, inputs and outputs by suitable arbitrary cones.The realization problem for cone systems has beenaddressed in [6, 9].

The first definition of the fractional derivative wasintroduced by Liouville and Riemann at the end of the19 century [12, 10, 20]. This idea has been used byengineers for modelling different process in the late1960s [28-30]. Mathematical fundamentals of fractionalcalculus are given in the monographs [10, 12, 20, 13,19]. The fractional order controllers have been developedin [18, 22]. A generalization of the Kalman filter forfractional order systems has been proposed in [26]. Someothers applications of fractional order systems can befound in [1, 15-17, 3, 11, 23, 24, 27, 28, 25]. In [14]a method for computation of the impulse responses fromthe frequency responses for the fractional standard (non-positive) discrete-time linear systems has been given.Fractional polynomials and nD systems have been inves-tigated in [4].

A new class of fractional linear continuous-time linearsystems described by the state equation is introduced.The solution to the state equations is derived using theLaplace transform. Necessary and sufficient conditions areestablished for the internal and external positivity of thefractional systems. Sufficient conditions are given for thereachability of the fractional positive systems.

Keywords: fractional, positive, continuous-time, linear,system, reachability.

th

In this paper a new class of fractional positive conti-nuous-time systems described by the state equations willbe introduced and the necessary and sufficient condi-tions for the internal and external positivity will beestablished.

The paper is organized as follows. In section 2 usingthe Caputo definition and Laplace transform the solutionto the state equations of the fractional systems is deri-ved. The necessary and sufficient conditions for theinternal and external positivity of the fractional systemsare established in section 3. In section 4 the reachabilityof the positive fractional systems is investigated. Conclu-ding remarks are given in section 5.

To the best knowledge of the author the positive frac-tional continuous-time linear systems have not beenconsidered yet.

The following notation will be used in the paper.The set of real matrices will be denoted and

. The set of real matrices with nonnega-tive entries will be denoted by andA matrix with nonnegative entries will be also denotedby . The set of nonnegative integers will be denotedby and the identity matrix by

In this paper the following Caputo definition of thefractional derivative will be used [10, 20]

(1)

where is the order of fractional derivative and

.

Consider the continuous-time fractional linear systemdescribed by the state equations

(2a)

(2b)

where are the state,input and output vectors and

.

The solution of equation (2a) is given by

(3)

A

.

2. Continuous-time fractional linear systemsand their solutions

Theorem 1.

REACHABILITY OF FRACTIONAL POSITIVE CONTINUOUS-TIME

LINEAR SYSTEMS

Tadeusz Kaczorek

Received 18 April 2008; accepted 9 June 2008.th th

Journal of Automation, Mobile Robotics & Intelligent Systems VOLUME 3, N° 1 2009

Regular papers 3

where

(4)

(5)

and is the Mittage-Leffler matrix function,

is the gamma function.

Using the Laplace transform ( ) to (2a) andtaking into account that

(6)

we obtain

(7)

whereIt is easy to check that

(8)

since

(9)

Substitution of (8) into (7) yields

(10)

Using the inverse Laplace transformation ( ) to (10)and the convolution theorem we obtain

(11)

where

Note that the solution (3) of (2a) forand is the same as in [28] but the second term of(3) is different.

From (4) and (5) for we have

Proof.

Remark 1.

�

Remark 2.

Example 1.

From the classical Cayley-Hamilton theo-rem we have

If

then

(13)

Find the solution of equation (2a) forand

Using (4) and (5) we obtain

(15a)

(15b)

since

Substitution of (15) and into(3) yields

since

(12)

(14)

(16)

The fractional system (2) is called theinternally positive fractional system if and only if

and for for any initial condi-tions and all inputs .

A square real matrix is called the Metzler ma-trix if its off-diagonal entries are nonnegative, i.efor [1, 5].

Let and . Then

(17)

and

(18)

3. Positivity of continuous-time fractionalsystemsDefinition 1.

Lemma 1.

Journal of Automation, Mobile Robotics & Intelligent Systems

Regular papers4

VOLUME 3, N° 1 2009

define the impulse response matrix of thesystem (2).

The impulse responsematrix of the system (2) is given by

(22)

Substitution of (3) into (2b) for yields

(23)

The formula (22) follows from (23) for .

The continuous-time fractional system (2)is externally positive if and only if its impulse responsematrix (22) is nonnegative, i.e.

(24)

The necessity of the condition (24) followsimmediately from Definition 2. The output of thesystem (2) with zero initial conditions for any inputis given by the formula

(25)

which can be obtained by substitution of (22) into (23).If the condition (24) is met and then from

(25) we have for .

From (22) and (18) it follows that if is a Metzlermatrix and (21) holds then the impulse response matrix(22) is nonnegative. Therefore, we have the following twocorollaries.

The impulse response matrix (22) of theinternally positive system (2) is nonnegative.

Every continuous-time fractional inter-nally positive system (2) is also externally positive.

The state of the fractional sys-tem (2) is called reachable in time if there exist an in-put which steers the state of sys-tem (2) from zero initial state to the state .If every stat is reachable in time the systemis called reachable in time . If for every statethere exist a time such that the state is reachable in time

then the system (2) is called reachable.

A real square matrix is called monomial if and only ifeach its row and column contains only one positive entryand the remaining entries are zero.

The continuous-time fractional system(2) is reachable in time if the matrix

(26)

is a monomial matrix.The input which steers the state of the system (2)

from to is given by the formula

Theorem 3.

Proof.

Corollary 1.

Corollary 2.

Definition 3.

Theorem 4.

�

A

4. Reachability

if and only if is a Metzler matrix.

From the expansion

it follows that and for smallonly if is a Metzler matrix.

It is well-known [5] that

(19)

if and only if is a Metzler matrix.Using (17) we may write

(20)

since for .Thus from (20) and (19) we have .The proof for (18) is similar.

The continuous-time fractional system (2)is internally positive if and only if the matrix is a Metz-ler matrix and

(21)

By Theorem 1 the solution of theequation (2a) has the form (3) and if (18)holds and is a Metzler matrix since

and for .

Let and (the thcolumn of the identity matrix ). The trajectory of thesystem does not leave the orthant only if

what implies for . Thematrix has to be a Metzler matrix. For the same reason,for we have what implies

since may be arbitrary. From (2b)for we have andand , since may be arbitrary. In a simi-lar way, assuming we obtainand since may be arbitrary.

The fractional system (2) is called exter-nally positive if and only if for every in-put and .

The impulse response of single-input single-out-put system is called its output for the input equal to theDirac impulse with zero initial conditions. Assumingsuccessively that only one input is equal to and theremaining inputs and initial conditions are zero we may

A

A

A

A

A

i

A

Proof. Necessity.

Sufficiency.

Theorem 2.

Proof. Sufficiency.

Necessity.

Definition 2.

�

�


Regular papers 5

VOLUME 3, N° 1 2009

(27)

where denotes the transpose.

If the matrix (26) is a monomial matrix thenand the input defined by (27) is an non-

negative vector, i.e. Using (3) for, (27) and (26) we obtain

Therefore, the input (27) steers the state of the sys-tem (2) from to .

If andis a monomial matrix then the continuous-

time fractional system (2) is reachable.

From (5) it follows that if the matrix isdiagonal then the matrix is also diagonal and thematrix is monomial since the matrix by assump-tion is monomial. From (26) written in the form

(28)

it follows that the matrix (28) is monomial. Thus by The-orem 3 the fractional system is reachable.

We shall show that the fractional system(2) with

(29)

is reachable.Taking into account that

and using (5) we obtain

(30)

where

and

In this case from (28) we have(31)

The matrix (31) is monomial and by Theorem 3 thefractional system is reachable.

T

A

B

Proof.

Theorem 5.

Proof.

Example 2.

�

�

Remark 3. It is well-known that the system

(32)

with

(33)

is reachable for any values of the coefficientssince the reachability matrix

(34)

The system (32) is also reachable as a positive systemif . The fractional system (2) with(33) even for is reachable if andonly if there exist such that the fol-lowing condition is met

(35)

The condition (35) follows from (3) for , (34)and that for , for

and

This example shows that the reachability conditionsfor the positive system (2) are much stronger than theconditions for positive system (32).

A new class of fractional positive continuous-timesystems has been introduced. The solution to the stateequation describing the fractional systems has beenderived using the Laplace transform (Theorem 1). Theclassical Cayley-Hamilton theorem has been extended forthe fractional systems (Remark 2). Necessary and suffi-cient conditions have been established for the internaland external positivity of the fractional systems (Theo-rem 2 and 3). Sufficient conditions for the fractionalpositive systems are much stronger than for classicalpositive systems. The considerations have been illustra-ted by examples of fractional continuous-time linearsystems.

The considerations presented for the reachability canbe extended for controllability of the fractional conti-nuous-time systems.

5. Concluding remarks


Regular papers6

VOLUME 3, N° 1 2009

ACKNOWLEDGMENTS

AUTHORTadeusz Kaczorek

References

This work was supported by Ministry of Science and HigherEducation in Poland under work No N514 1939 33.

[1] N. Engheta, “On the role of fractional calculus in ele-ctromagnetic theory”, , vol. 39,no. 4, 1997, pp. 35-46.

[2] L. Farina and S. Rinaldi, Positive Linear Systems;, J. Wiley, New York, 2000.

[3] N.M.F. Ferreira and J.A.T. Machado, “Fractional-orderhybrid control of robotic manipulators”. In:

ICAR'2003, Coimbra,Portugal, pp. 393-398.

[4] K. Gałkowski, A. Kummer, “Fractional polynomials andnD systems”. In:

, ISCAS'2005, Kobe, Japan, CD-ROM.[5] T. Kaczorek, , Springer-

Verlag: London, 2002.[6] T. Kaczorek, “Computation of realizations of discrete-

time cone systems”, , vol. 54,no. 3, 2006, pp. 347-350.

[7] T. Kaczorek,

.[8] T. Kaczorek, “Reachability and controllability to zero

of positive fractional discrete-time systems”,, vol. 6, no. 4, 2007.

[9] T. Kaczorek, “” (in press).

[10] K. S. Miller and B. Ross,, Willey:

New York, 1993.[11] M. Moshrefi-Torbati and K. Hammond,

, J. Fran-klin Inst., vol. 335B, no. 6, 1998, pp. 1077-1086.

[12] K. Nishimoto, , Decartess Press:Koriama, 1984.

[13] K. B. Oldham and J. Spanier, ,Academic Press: New York, 1974.

[14] M. D. Ortigueira, “Fractional discrete-time linear sys-tems”. In: , Munich, Germany,IEEE, New York, vol. 3, pp. 2241-2244.

[15] P. Ostalczyk, “The non-integer difference of the dis-crete-time function and its application to the controlsystem synthesis”, , vol. 31, no. 12,2000, pp. 1551-1561.

[16] P. Ostalczyk, “Fractional-Order Backward DifferenceEquivalent Forms Part I Horner's Form”. In:

,FDA'04, Enseirb, Bordeaux, France, 2004, pp. 342-347.

[17] P. Ostalczyk, “Fractional-Order Backward DifferenceEquivalent Forms Part II Polynomial Form”. In:

- Professor at Białystok Technical Uni-versity, Faculty of Electrical Engineering, Wiejska 45D,15-351 Białystok, Poland.E-mail: [email protected].

IEEE Trans. Atenn. Prop.

Theoryand Applications

Proc. 11Int. Conf. Advanced Robotics,

Proc IEEE Int. Symp. Circuits and Sys-tems

Positive 1D and 2D Systems

Bull. Pol. Acad. Sci. Techn.

Reachability and controllability to zerotests for standard and positive fractional discrete-timesystems

MachineIntelligence and Robotic Control

Reachability and controllability to zero ofcone fractional linear systems

An Introduction to the FractionalCalculus and Fractional Differenctial Equations

Physical and geo-metrical interpretation of fractional operator.

Fractional Calculus

The Fractional Calculus

Proc. of the IEE-ICASSP 97

Int. J. Syst, Sci.

Proc. 1 IFACWorkshop Fractional Differentiation and its Applications

Proc. 1IFAC Workshop Fractional Differentiation and its

th

st

st

Applications

Commande CRONELa dérivation non entiére

Fractional Differential Equations

Fract. Calc. Appl. Anal.

Proc. 36 IEEE Conf. Decision and Control

J. Optoel. Adv. Mat.

Proc. IEEEInt. Electric Machines and Drives Conference

FractionalIntegrals and derivative. Theory and Applications

Int. J. Appl. Math. Comp.Sci.

VehicleSyst. Dynam.

Fractionalorder systems and fractional order control actions. Lec-ture 3 IEEE CDC'02 TW#2: Fractional calculus Applicationsin Autiomatic Control and Robotics

Proc. 41 IEEE Conf. Decision and Control

Proc.Int. Conf. Info-tech and Info-net

, FDA'04, Enseirb, Bordeaux, France, 2004,pp. 348-353.

[18] A. Oustalup, , Hermés: Paris, 1993.[19] A. Oustalup, , Hermés: Paris,

1995.[20] I. Podlubny, , Academic

Press: San Diego, 1999.[21] I. Podlubny, “Geometric and physical interpretation of

fractional integration and fractional differentiation”,, vol. 5, no. 4, 2002, pp. 367-386.

[22] I. Podlubny, L. Dorcak and I. Kostial, “On fractional de-rivatives, fractional order systems and PI D -control-lers”. In: , SanDiego, CA, 1997, pp. 4985-4990.

[23] M.E. Reyes-Melo, J.J. Martinez-Vega, C.A. Guerrero-Salazar and U. Ortiz-Mendez, “Modelling and relaxationphenomena in organic dielectric materials. Applica-tion of differential and integral operators of fractio-nal order”, , vol. 6, no. 3, 2004,pp. 1037-1043.

[24] D. Riu, N. Retiére and M. Ivanes, “Turbine generatormodeling by non-integer order systems”. In:

, IEMDC2001, Cambridge, MA, 2001, pp. 185-187.

[25] S. G. Samko, A.A. Kilbas and O.I. Martichew,.

Academic Press: London, 1993.[26] D. Sierociuk and D. Dzieliński, “Fractional Kalman filter

algorithm for the states, parameters and order of frac-tional system estimation”,

, vol. 16, no. 1, 2006, pp. 129-140.[27] M. Sjöberg and L. Kari, “Non-linear behavior of a rubber

isolator system using fractional derivatives”,, vol. 37, no. 3, 2002, pp. 217-236.

[28] B. M. Vinagre, C. A. Monje and A.J. Calderon,

.[29] B. M. Vinagre and V. Feliu, “Modeling and control of

dynamic system using fractional calculus: Applicationto electrochemical processes and flexible structures”.In: , Las Vegas,NV, 2002, pp. 214-239.

[30] V. Zaborowsky and R. Meylaov, “Informational networktraffic model based on fractional calculus”. In:

, ICII 2001, Beijing,China, vol. 1, pp. 58-63.

� μ

th

st


Regular papers 7

VOLUME 3, N° 1 2009

Abstract:

1. IntroductionA dynamical system without input signal is called

pointwise complete if every final state can be reached bysuitable choice of the initial state. The system, which isnot pointwise complete, is called pointwise degenerated.

The problem of pointwise completeness and point-wise degeneracy of linear continuous-time systems withdelays has been considered in [5, 14, 16, 18].

The problem of pointwise completeness and point-wise degeneracy of linear discrete-time systems withdelays has been formulated and solved in [1, 2] for thestandard systems and in [4] for the positive systems.

In positive systems inputs, state variables and out-puts take only non-negative values. Examples of positivesystems are industrial processes involving chemical reac-tors, heat exchangers and distillation columns, storagesystems, compartmental systems, water and atmosphericpollution models. A variety of models having positivelinear systems behaviour can be found in engineering,management science, economics, social sciences, bio-logy and medicine, etc. An overview of state of the art inpositive systems is given in the monographs [7, 10].

In the last decades, the problem of analysis and syn-thesis of dynamical systems described by fractional orderdifferential (or difference) equations was considered inmany papers and books (see [6, 15, 17], for example).

The new class of linear systems of fractional order, na-mely the positive fractional systems, has been introducedin [11-13].

In this paper we consider the problem of pointwisecompleteness and pointwise degeneracy of linear conti-nuous-time systems of fractional order. Definitions andnecessary and sufficient conditions for the pointwisecompleteness and the pointwise degeneracy of fractional

A dynamical system described by homogeneous equa-tion is called pointwise complete if every final state can bereached by suitable choice of the initial state. The system,which is not pointwise complete, is called pointwise dege-nerated. Definitions and necessary and sufficient condi-tions for the pointwise completeness and the pointwisedegeneracy of continuous-time linear systems of fractionalorder, standard and positive, are given. It is shown that:1) the standard fractional system is always pointwise com-plete; 2) the positive fractional system is pointwise com-plete if and only if the state matrix is diagonal.

Keywords: inear system, fractional, continuous-time, posi-tive, pointwise completeness.

systems standard and positive will be given.To the best knowledge of the authors the pointwise

completeness and pointwise degeneracy of fractionalorder systems have not been considered yet

Consider the fractional continuous-time linear systemdescribed by the homogeneous equation

(1)

where is the order of fractional derivative,and .

The following Caputo definition of the fractional-order derivative will be used [12]

(2)

where is the Euler gamma function and

is an integer satisfying the inequality .It is easy to see that for we have and

(2a)

The solution of equation (1) with is givenby [12]

(3)

where

(4)

is the fundamental matrix and is the Mittage-Leffler matrix function.

The fundamental matrix depends on the timeand the matrix .

The fundamental matrix (4) is always non-singular, i.e.

(5)

for all and for any matrix .

.In the paper the following notation will be used:

- the set of real matrices and- the set of real matrices with non-negative

entries and - the identity matrix.

2. The main results2.1. Standard systems

�

p

tA

p=1

Lemma 1.

POINTWISE COMPLETENESS AND POINTWISE DEGENERACY

OF LINEAR CONTINUOUS-TIME FRACTIONAL ORDER SYSTEMS

Tadeusz Kaczorek, Mikołaj Busłowicz

Received 3 September 2008; accepted 14 November 2008.rd th


Regular papers8

Proof.

Lemma 2.

Example 1.

Lemma 3.

Let us consider the function

(6)

We show that for any matrix .Note that the function (6) is well definite on the

spectrum of the matrix . Let be real orcomplex eigenvalues (not necessarily distinct) of .Then from (6) it follows that for any real

and for anycomplex conjugate pair

It is well known [8, 9] that the eigenvalues of thematrix are:and

(7)

The fundamental matrix (4) can be computed by usingthe Sylvester formula [8, 9]. In the case of distincteigenvalues of we have the following lemma.

If has only distinct eigenvalues thenthe fundamental matrix (4) can be computed from theformula

(8)

Using the Sylvester formula check thefundamental matrix of the system (1) with

(9)

The matrix (9) has two distinct eigenvalues:and In this case, according to Sylvester formula(8), we have

where

From (4) it follows that the fundamental matrix canbe written in the form

where

From (12) we have the following lemma.

If is a nilpotent matrix with the nilpoten-cy index (i.e. for and )then

(14)

AA

Aμ

(10)

(11)

(12)

(13)

�

�

A

A

By generalisation of definitions of pointwise com-pleteness and pointwise degeneracy to the case of frac-tional order systems (1) one obtains the following defi-nitions.

The fractional system (1) is calledpointwise complete at if for every final vector

there exists an initial state such that.

The fractional system (1) is called point-wise degenerated in the direction at if there existsa non-zero vector such that for all initial states

the solution of (1) for satisfies the condi-tion , where denotes the transpose.

From the above definitions and Lemma 1 we have thefollowing important theorem.

The fractional continuous-time system(1) is always pointwise complete, i.e. for any finitestate there exists the initial state

such that

From Lemma 1 we have that forany matrix and for all Hence, from (3) itfollows that for any given finite state we can alwayscompute the initial state from the formula (15).

Consider the system (1) with

It is easy to see that (16) is a nilpotent matrix withthe nilpotency index i.e.

From Lemma 3 for we have

where is defined by (13) for .

From Theorem 1 it follows that the fractional sys-tem is pointwise complete and for any final state

we can find the suitable ini-tial state from the formula

If, for example, and then

Definition 1.

Definition 2.

Theorem 1.

Proof.

Example 2.

v

(15)

(16)

(17)

(18)

(19)

T

�


for

Regular papers 9

If then from (15) we have

3. Concluding remarksThe paper considers the problem of pointwise com-

pleteness and pointwise degeneracy of linear continuous-time systems of fractional order, described by thehomogeneous equation (1). First, the definitions of thepointwise completeness and pointwise degeneracy of thestandard (i.e. non-positive) fractional systems have beenintroduced (Definitions 1 and 2) and it has been provedthat the fractional continuous-time system (1) is alwayspointwise complete (Theorem 1). Next, the definitions(Definitions 4 and 5) and necessary and sufficient condi-tions of the pointwise completeness (Theorem 3) andpointwise degeneracy (Theorem 4) of the positive frac-tional systems have been given. It has been shown thatthe positive system (1) is pointwise complete if and onlyif the state matrix is diagonal.

The considerations can be extended for the fractionaldiscrete-time systems [3].

- BiałystokTechnical University, Faculty of Electrical Engineering,ul. Wiejska 45D, 15-351 Białystok, Poland, E-mails:[email protected], [email protected].* Corresponding author

A

AUTHORSTadeusz Kaczorek and Mikołaj Busłowicz*

References[1] Busłowicz M., "Controllability of linear discrete-delay

systems". In:, Błażejewko, Poland, 1981,

pp. 47-51.[2] Busłowicz M., "On some properties of solution of state

equation of discrete-time systems with delays",, vol. 1, 1983, pp.

17-29 (in Polish).[3] Busłowicz M., "Pointwise completeness and pointwise

degeneracy of linear discrete-time systems of fractionalorder", no. 151,2008, pp. 19-24 (in Polish).

[4] Busłowicz M., Kociszewski R., Trzasko W., "Pointwise com-pleteness and pointwise degeneracy of positive discrete-time systems with delays",

, no. 145, 2006, pp. 51-56 (in Polish).[5] Choundhury A. K., "Necessary and sufficient conditions

of pointwise completeness of linear time-invariantdelay-differential systems", , vol. 16 (6),1972, pp. 1083-1100.

[6] Das. S,, Springer, Berlin 2008.

[7] Farina L. and Rinaldi S.,, J. Wiley: New York, 2000.

[8] Gantmacher F. R., , vol. I and II,Chelsea: New York, 1960.

[9] Kaczorek T.,

Proc. Intern. Conf. Functional DifferentialSystems and Related Topics

Zesz.Nauk. Polit. Biał., Elektrotechnika

Zesz. Nauk. Pol. Śląskiej, Automatyka,

Zesz. Nauk. Pol. Śląskiej,Automatyka

Int. J. Control

Functional Fractional Calculus for System Identifi-cation and Controls

Positive Linear Systems; Theoryand Applications

Theory of Matrices

Vectors and Matrices in Automatics and

2.2. Positive systemsDefinition 3.

Theorem 2.

Definition 4.

Definition 5.

Theorem 3.

Proof.

Theorem 4.

Example 3.

Example 4.

The fractional system (1) is called posi-tive if and only if for any .

A square real matrix is called the Metzlermatrix if its off-diagonal entries are non-negative, i.e.

for .In the paper [12] the following theorem has been

proved.

The fractional system (1) is positive if andonly if the matrix is a Metzler matrix.

Definitions of pointwise completeness and pointwisedegeneracy of positive fractional system (1) can beformulated as follows.

The positive fractional system (1) is cal-led pointwise complete at if for every vectorthere exists an initial state such that .

The positive fractional system (1) is cal-led pointwise degenerated if it is not pointwise complete,that is there exists at least one state which cannot be reached from any initial state i.e. doesnot exist and such that .

The positive fractional system (1) is point-wise complete at if and only if the matrix isdiagonal.

In positive systems, according to Definition 3,and . From (15) it follows that for anythere exists if and only if

. It is well known [10] that if andonly if is a monomial matrix (in each row and ineach column only one entry is positive and remainingentries are zero). From (12) it follows that isa monomial matrix if and only if the matrix is dia-gonal.

From Definition 5 and Theorem 3 we have the follo-wing theorem.

The positive fractional system (1) ispointwise degenerated if and only if is not a diagonalmatrix.

In Example 2 it was shown that thestandard system (1) with the Metzler matrix (16) ispointwise complete.

From (19) it follows that if and then. This means that the system with the Metzler

matrix (16), analysed as a positive system, is pointwisedegenerated. This result also follows from Theorem 3.

Consider the positive system (1) with thematrix (9). Fundamental matrix of the system has theform (10).

By Theorem 3 the positive fractional system is point-wise complete at any since the matrix (10) is dia-gonal. Using (15) we may find for any given

.

A

A

A

A�


Regular papers10

ElectrotechnicsPositive 1D and 2D Systems

MachineIntelligence and Robotics Control

Int. J. Appl. Math.Comput. Sci.

Journal of Automation and System Engi-neering

Ricerche di Auto-matica

Fractional Differential Equations

Journal of Diff.Equations

Advances in Fractional Calculus, Theoretical Develop-ments and Applications in Physics and Engineering

Lecture Notes in MathematicsSeminar on Differential Equations and Dynamic

System II

, WNT, Warszawa 1998 (in Polish).[10] Kaczorek T., , Springer,

London 2002.[11] Kaczorek T., "Reachability and controllability to zero of

positive fractional discrete-time systems",, vol. 6, no.4, 2008,

pp. 139-143.[12] Kaczorek T., “Fractional positive continuous-time linear

systems and their reachability”,, vol. 18, no. 2, 2008, pp. 223-228.

[13] Kaczorek T., "Reachability and controllability to zerotests for standard and positive fractional discrete-timesystems",

, vol. 42, no. 6-7-8, 2008, pp. 769-787.[14] Olbrot A., "On degeneracy and related problems for

linear constant time-lag systems"., vol. 3, no. 3, 1972, pp. 203-220.

[15] Podlubny I., , AcademicPress, San Diego 1999.

[16] Popov V. M., "Pointwise degeneracy of linear time-invariant delay-differential equations",

, issue 11, 1972, pp. 541-561.[17] Sabatier J., Agrawal O. P. and Machado J. A. T. (Eds),

,Springer London 2007.

[18] Weiss L., "Controllability for various linear and nonli-near systems models", ,vol. 144,

, Springer, Berlin 1970, pp. 250-262.


Regular papers 11

Abstract:

1. Introduction

2. Preliminaries and problem formulation

The paper considers the stability problem of linear time-invariant continuous-time systems of fractional commen-surate order. It is shown that the system is stable if andonly if plot of rational function of fractional order (calledthe generalised modified Mikhailov plot) does not encirclethe origin of the complex plane. The considerations areillustrated by numerical examples.

Keywords: stability, linear system, continuous-time, frac-tional, commensurate order.

In the last decades, the problem of analysis andsynthesis of dynamical systems described by fractionalorder differential (or difference) equations was consi-dered in many papers, see [4, 9, 10, 12, 18, 21, 23], forexample. Some applications of fractional order systemscan be found in [5, 19, 20-22]. The stability problem oflinear continuous-time systems of fractional order hasbeen studied in [2, 3, 6, 7, 8, 23]. The new class of thelinear fractional order systems, namely the positivesystems of fractional order has been considered in[15-17].

The aim of this paper is to give the new frequency do-main methods for stability analysis of linear continuous-time fractional systems in the case of commensurate de-gree characteristic polynomials. To the best knowledge ofthe Author, computationally effective frequency domainmethods for stability analysis of fractional commensura-te degree polynomials have not been proposed yet

A linear single input, single output continuous-timedynamical system of fractional order is described by thefollowing fractional differential equation (see [23] forexample)

(1)

where is the input, is the output,and are ar-

bitrary real numbers, andare real coefficients and

(2)

is the Caputo definition for fractional -order derivative

where is the Euler gamma function

.

u t( ) y t( )

�

and is an integer satisfying inequality .Applying the Laplace transform to both sides of equa-

tion (1) and assuming zero initial conditions, we obtainthe following fractional order transfer function

The fractional order linear system with the transferfunction (3) is of [23]:

commensurate order if

where is a real number,

The transfer function of fractional system of commen-surate order can be written in the form

Substituting in (5), one obtains the associa-ted natural order transfer function

If, for example,

then for one obtains the associated natural or-der transfer function

Characteristic polynomial of the fractional system (1)has the form

The polynomial (8) is a multivalued function whosedomain is a Riemann surface. In general, this surface hasan infinite number of sheets and the fractional polyno-mial (8) has an infinite number of zeros. Only a finitenumber of which will be in the main sheet of the Riemannsurface. For stability reasons only the main sheet definedby can be considered [23].

[7, 8, 23]. The fractional order system withthe transfer function (3) is bounded-input bounded-

p

(3)

(4)

rational order if it is a commensurate order andwhere is a positive integer,

non-commensurate order if (4) does not hold.

(5)

(6)

(7a)

(7b)

(8)

�

> 0�

�

�

� =1 / q q

Theorem 1

STABILITY ANALYSIS OF LINEAR CONTINUOUS-TIME FRACTIONAL SYSTEMS

OF COMMENSURATE ORDER

Mikołaj Busłowicz

Received 27 May 2008; accepted 13 August 2008.th th


Regular papers12

output (BIBO) stable (shortly stable) if and only if thefractional degree characteristic polynomial (8) is stable,i.e. this polynomial has no zeros in the closed right halfof the Riemann complex surface, that is

(9)

The Riemann surface has a finite number of sheetsonly in the case of fractional polynomials (8) of commen-surate degree, i.e. for

(10)

If (10) holds, the fractional degree characteristicpolynomial (8) can be written in the form

(11)

Hence, for from (11) we obtain the associatednatural number degree polynomial

(12)

If, for example, ( and arereal numbers) then , and the associa-ted natural number degree polynomial has the form

[23]. The fractional commensurate degreecharacteristic polynomial (11) is stable if and only if allzeros of this polynomial satisfy the condition (9) or,equivalently, all zeros of the associated natural degreepolynomial (12) satisfy the condition

(13)

If then from (13) we obtain the stability regionshown in Figure 1.

Parametric description of the boundary of the stabi-lity region has the form

(14)

The polynomial (11) with is a natural number

a b

Theorem 2

Fig. 1. Stability region of fractional degree polynomial(11) in the complex -plane with .

� = 1

degree polynomial and from (14) we have that the ima-ginary axis of the complex plane is the boundary of thestability region.

From the above and Theorem 2 we have the followingsufficient condition for stability of fractional degree po-lynomial (11) with .

The fractional commensurate degree cha-racteristic polynomial (11) with is stable if theassociated natural number degree polynomial (12) isasymptotically stable, i.e. the condition (13) holds for

which means that for all zerosof (12).

From Theorem 2 it follows that the fractional polyno-mial (11) may be stable in the case when the associatednatural degree polynomial (12) is not asymptoticallystable.

Stability checking of the fractional degree polynomial(11) on the basis of Theorem 2 is a difficult problem ingeneral, because the degree of the associated polynomial(12) may be very large. If, for example,

then for one obtains the associatedpolynomial of natural degree [6]

The above polynomial has degree equal to 127 andonly five non-zero coefficients.

To avoid this difficulty, a method for determination ofthe multi-variate natural degree polynomial, associatedwith the fractional commensurate degree polynomial hasbeen given in [6]. To stability analysis of multi-variatedegree polynomials, the LMI technique has been propo-sed in [6].

The aim of this paper is to give the new frequency do-main methods for stability analysis of fractional polyno-mials of commensurate degree. The methods proposedare based on the Mikhailov stability criterion and themodified Mikhailov stability criterion, known from thetheory of systems of natural number order (see [1, 14,24], for example).

Lemma 1.

� = 1,

In the stability theory of natural degree characteristicpolynomials of linear continuous-time systems, the fol-lowing kinds of stability are considered (see [1], forexample):

asymptotic stability (all zeros of the characteristicpolynomial have negative real parts),D-stability (all zeros of the characteristic polynomiallie in the open region D in the left half-plane ofcomplex plane).From the above and Theorem 2 we have the following

lemma.

The fractional degree polynomial (11) isstable if and only if the associated natural degree polyno-mial (12) is D-stable, where the parametric descriptionthe boundary of the region D has the form (14). In parti-

3. Solution of the problem

�

�

Lemma 2.


Regular papers 13

which holds if and only if (18) is satisfied.The reference fractional polynomial can be cho-

sen in the form

(21)

Note that for the reference polynomial (21) isstable.

Plot of the function isdefined by (16) we will called the generalised modifiedMikhailov plot.

The condition (18) of Theorem 4 holds if and only ifthe generalised modified Mikhailov plot does not encirclethe origin of the complex plane as runs from to .

From (11), (16) and (21) we have

(22)

and

(23)

From (23) it follows that ifHence, from Theorem 4 we have the following importantlemma.

The fractional degree polynomial (11) isnot stable if .

Now we consider the case in which the condition (18)of Theorem 4 does not hold.

The fractional characteristic polynomial(11) of commensurate degree has zeros in the righthalf of the Riemann complex surface if and only if asruns from to the plot of times encirc-lese in the negative direction the origin of the complexplane. In such a case

(24)

As in [14] in the case of natural degree poly-nomials we can show that if the fractional degree poly-nomial (11) has zeros with positive real parts, then

(25)

Hence, from (20) and (19), (25) it follows that (24)holds. If (24) holds then from (20) and (19) we have (25).

It is easy to see that Theorem 4 follows from Theorem5 for .

Consider a linear fractional order system with cha-racteristic polynomial of commensurate degree of theform [6]

�

�

c

k

k

k

> 0

)

0

0

= 0

Lemma 3.

Theorem 5.

Proof.

Example 1.

�

�

4. Illustrative examples

cular, for the D-stability region is shown inFigure 1.

It is easy to see that if then the fractionaldegree polynomial (11) is reduced to the natural degreepolynomial (12) with . In such a case from (14) itfollows that boundary of the stability region is the ima-ginary axis of the complex plane.

The fractional degree characteristic poly-nomial (11) is stable if and only if

(15)

where for

It is easy to see thatThis means that (15) is the necessary and sufficientcondition for D-stability of the natural degree polynomial(12) [1]. Hence, the proof follows from Lemma 2.

Plot of the function where forwill be called the generalised (to the class of

fractional degree polynomials) Mikhailov plot.Satisfaction of (15) means that the generalised Mik-

hailov plot starts for in the point on realaxis and with increasing from to turns strictlycounter-clockwise and goes through quadrants of thecomplex plane.

Checking the condition (15) of Theorem 3 is difficultin general (for large values of ), because quicklytends to infinity as grows to .

To remove this difficulty, we consider the rationalfunction

(16)

instead of the polynomial (11), where is the refe-rence fractional polynomial of the same degree as poly-nomial (11).

We will assume that the reference fractional polyno-mial is stable, i.e.

for (17)

The fractional degree polynomial (11) isstable if and only if

(18)

where for and is defined by(16).

If the reference polynomial is stablethen from Theorem 3 we have

(19)

From (16) for it follows that

(20)

The fractional degree polynomial (11) is stable if andonly if

� = 1

0

Theorem 3.

Proof.

Theorem 4.

Proof.

�

n

n


Regular papers14

(26)

For and from the fractionalcommensurate degree polynomial (26) we obtain theassociated natural degree polynomial

(27)

From Theorem 2 it follows that the fractional degreepolynomial (26) is stable if and only if the associatednatural degree polynomial (27) has no zeros in the coneshown in Figure 1 with .

Plot of the function (16) withis shown in Figure 2. According to (22) and (23) we have

From Figure 2 it follows that the generalised modifiedMikhailov plot does not encircle the origin of thecomplex plane and the system is stable, according toTheorem 4.

Now we consider the fractional degree polynomial(26) and associated natural degree polynomial (27) in thecase when the free term has negative sign, i.e. is

instead of . In such a caseand the fractional

system is not stable, according to Lemma 3.

Fig. 2. Plot of the function (16) with .

-221.9590294 +221.9590294

In this case, the generalised modified Mikhailov plotwith the reference polynomial isshown in Figure 3, where

Zeros of natural degree polynomial (27) with negativefree term and the boundary of the stability region areshown in Figure 4.

From Figure 3 it follows that the generalised modifiedMikhailov plot ones encircles the origin of thecomplex plane in negative direction. This means, accor-ding to Theorem 5, that the system is unstable and thecharacteristic polynomial has one unstable zero. This ze-ros lies in the instability region shown in Figure 4.

Consider the control system with thefractional order plant described by the transfer function[11, 25]

(28)

and the fractional PD controller (designed in [11])

(29)

Characteristic polynomial of the closed loop systemwith the plant (28) and controller (29) has the form

Fig. 3. Plot of the function (16) withof the form (26) with negative free term.

Fig. 4. Zeros of polynomial (27) with negative free term andboundary of the stability region.

D(s)

Example 2.


Regular papers 15

(30)

Substituting and in (30),one obtains the associated polynomial of natural degree

(31)

The control system is stable if and only if all zeros ofpolynomial (31) lie in the stability region shown in Figure1 with .

To stability checking of fractional polynomial (30) weapply Theorem 4.

Plot of the function wherehas the form (30) and is the

reference fractional polynomial, is shown in Figure 5.

From (22) and (23) we have

From Figure 5 it follows that the generalised modifiedMikhailov plot does not encircle the origin of thecomplex plane. This means that the fractional controlsystem is stable, according to Theorem 4.

New frequency domain methods for stability analysisof linear systems of fractional commensurate order havebeen given.

The methods have been obtained by generalisation ofthe Mikhailov stability criterion and the modified Mikha-ilov stability criterion (known from the theory of naturalorder systems) to the case of fractional order systems.

In particular it has been shown that:the fractional polynomial (11) is stable if and only ifplot of with increasing from to turnsstrictly counter-clockwise and goes through qua-drants of the complex plane (Theorem 3),the fractional polynomial (11) is stable if and only ifplot of the rational functionwhere is defined by (16), called the generalisedmodified Mikhailov plot, does not encircle the originof the complex plane (Theorem 4),

D s

D jn

js

( )

( ) 0

( ),( )

Fig. 5. Plot of the function .

5. Concluding remarks

�

�

� �

� �

�

the fractional characteristic polynomial (11) haszeros in the right half of the Riemann complex surfaceif and only if as runs from to the generalisedmodified Mikhailov plot times encircles inthe negative direction the origin of the complex plane(Theorem 5).

The effectiveness of the methods has been illustratedby numerical examples.

Generalisation of the main result of the paper (Theo-rem 4) for the fractional systems of non-commensurateorder has been given in [2].

The preliminary version of this paper was presentedat the conference Automation'2008 which was held inWarsaw, Poland and published in [3].

The considerations can be generalised to the linearfractional order systems with delays.

- Professor at Białystok TechnicalUniversity, Faculty of Electrical Engineering, ul. Wiejska45D, 15-351 Białystok, Poland.E-mail: [email protected].

� k �

�

0

ACKNOWLEDGMENTS

AUTHORMikołaj Busłowicz

References

The work was supported by the Ministry of Science and HighEducation of Poland under grant No. N N514 1939 33.

[1] Busłowicz M.,, Publishing Department of

Technical University of Białystok, Białystok 1997 (inPolish).

[2] Busłowicz M., "Frequency domain method for stabilityanalysis of linear continuous-time fractional systems".In: K. Malinowski, L. Rutkowski (Eds.):

Academic Publishing HouseEXIT: Warsaw 2008, pp. 83-92.

[3] Busłowicz M., "Stability of linear continuous-time frac-tional systems of commensurate order",

, no. 2, 2008, 475-484 (on CD-ROM) (inPolish).

[4] Das. S,, Springer, Berlin 2008.

[5] Ferreira N. M. F., Machado J. A. T., "Fractional-orderhybrid control of robotic manipulators". In:

, ICAR'2003, Coimbra 2003,Portugal, 393-398.

[6] Gałkowski K., Bachelier O., Kummert A., "Fractionalpolynomial and nD systems a continuous case. In:

, San Diego2006, USA.

[7] Matignon D., "Stability results on fractional differentialequation with applications to control processing". In:

, Lille 1996, France.[8] Matignon D., "Stability properties for generalized frac-

tional differential systems". In: , 1998,pp. 145-158.

[9] Ortigueira M. D., "Introduction to fractional linear sys-tems. Part 1: Continuous-time case". In:

Stability of linear time-invariant systemswith uncertain parameters

Recent Advancesin Control and Automation,

Pomiary Auto-matyka Robotyka

Functional Fractional Calculus for System Identi-fication and Controls

Proc. of 11Int. Conf. Advanced Robotics

Proc.of IEEE Conference on Decision & Control

Proc. of IMACS

Proc. of ESAIM

IEE Proc. – Vis.

th


Regular papers16


Image Signal Process

IEE Proc.– Vis. Image Signal Process

Fractional order systems and fractionalorder controllers.

Estimation and control of discrete dyna-mical systems of fractional order in state space

Theory of Control Systems

MachineIntelligence and Robotics Control

Pomiary Automatyka Robo-tyka

Int. J. Appl. Math.Comput. Sci.

Theory andApplications of Fractional Differential Equations

J. Optoel. Adv. Mat.

Proc. IEEEInt. Electric Machines and Drives Conference

Ad-vances in Fractional Calculus, Theoretical Developmentsand Applications in Physics and Engineering

ehicleSyst. Dynam.

Proc. of IEEE CDC'02 TW#2: FractionalCalculus Applications in Automatic Control and Robotics

Trans. ASME Journal Basic Eng.

Proc. IEEE Intern. Conf. on Mechatronics& Automation

, no. 147, 2000, pp. 62-70.[10] Ortigueira M. D., "Introduction to fractional linear

systems. Part 2: Discrete-time systems". In:, no. 147, 2000, pp. 71-78.

[11] Podlubny I.,The Academy of Sciences Institute of

Experimental Physis, Kosice, Slovak Republic, 1994.[12] Podlubny I., Fractional Differential Equations, Acade-

mic Press, San Diego 1999.[13] Sierociuk D.,

, PhDDissertation, Faculty of Electrical Engineering, WarsawUniversity of Technology, Warsaw 2007 (in Polish).

[14] Kaczorek T., , WNT: Warszawa,1974 (in Polish).

[15] Kaczorek T., "Reachability and controllability to zeroof positive fractional discrete-time systems",

, vol. 6, no. 4, 2008,pp. 139-143.

[16] Kaczorek T. "Reachability of fractional positive conti-nuous-time linear systems",

, no. 2, 2008, pp. 527-537 (on CD-ROM).[17] Kaczorek T, “Fractional positive continuous-time linear

systems and their reachability”,, vol. 18, no. 2, 2008, pp. 223-228.

[18] Kilbas A. A., Srivastava H. M. Trujillo J. J.,, Else-

vier, Amsterdam 2006.[19] Reyes-Melo E., Martinez-Vega J.J., Guerrero-Salazar

C.A., Ortiz-Mendez U., "Modelling and relaxation phe-nomena in organic dielectric materials. Application ofdifferential and integral operators of fractional order".

, vol. 6, no , 2004, pp. 1037-1043.[20] Riu D., Retiére N., Ivanes M., "Turbine generator

modeling by non-integer order systems". In:, IEMDC

2001, England, Cambridge, 2001, pp. 185-187.[21] Sabatier J., Agrawal O. P., Machado J. A. T. (Eds),

, Springer,London 2007.

[22] Sjöberg M., Kari L., "Non-linear behavior of a rubberisolator system using fractional derivatives". V

, vol. 37, no. 3, 2002, pp. 217-236.[23] Vinagre B. M., Monje C. A., Calderon A. J., "Fractional

order systems and fractional order control actions",Lecture 3. In:

,Las Vegas 2002.

[24] Wright W. C., Kerlin T. W., "An efficient computer orien-ted method for stability analysis of large multivariablesystems", , no. 92, 1970,pp. 279-286.

[25] Zhao Ch., Xue D., Chen Y.-Q. (2005), "A fractional orderPID tuning algorithm for a class of fractional orderplants". In:

, Niagara Falls 2005, Canada, pp. 216-221.

VOLUME 3, N° 1 2009

Regular papers 17


SPECIAL ISSUE SECTION

Dependability and Safety

of Real-Time Computer Systems

Editors:

Wojciech Grega,Andrew J. Kornecki,

Janusz Zalewski

20

It is our great pleasure to present our readers with this special issue of JAMRIS on. The articles in this issue are extended and revised versions of papers

that have been selected from submissions to the RTS'07, 2 Workshop on Real-Time Software, which tookplace as a part of the IMCSIT Conference (International Multi-conference on Computer Science and Infor-mation Technology), organised by the Polish Information Processing Society (PTI), in Wisła, Poland, 15 -17October 2007 (please see http://www.imcsit.org/ for details about this series of conferences).

In today's society, computers are omnipresent and are associated with almost all our activities.Computers are used in control and monitoring not only in industrial and scientific applications, as it used tobe a few years ago, but also in everyday life. Digital, microprocessor-based devices are present in everyaspect of our daily life, from door locks and alarm clocks, to cell phones, to cars, traffic lights, and medicalequipment, banking terminals, airplanes and space probes. The common characteristic of all these computer-controlled devices and systems is that they depend on the proper operation of microprocessors that areembedded in them, and run in real time, that is, their response time is bounded.

As a consequence, the widespread use of computers, which are all controlled by software, may posesignificant problems related to software dependability and safety. is a term in common use,but the accepted definition is not that well known. Dependability is “the property of a computer system,such that reliance can be justifiably placed on the services it delivers” (IFIP WG10.4, 1989). Such definitionreflects the fact that the concept of dependability is a complex one, and has several aspects. One of theseaspects involves dependability attributes, i.e., critical properties that constitute the notion of dependa-bility. Among such properties, those most commonly listed are: reliability, safety, and security.

Reliability and security are traditional properties of computer systems. Reliability is defined as “perfor-ming required functions under stated conditions for a specified period of time” (IEEE Glossary of SoftwareEngineering Terminology). The security essentially deals with protection from external threats. However,computer or software safety is a term not clearly defined and often misinterpreted. Essentially, it can bedescribed as freedom of risk, to a human or a society, caused by a computer or software. In this sense, sa-fety is a property very different from reliability, which reflects only performing required functions withouttaking into account risks, and is a direct inversion of security, in a sense that security deals with protectinga computer system from external threats, while safety deals with protecting the external world from theconsequences of a computer malfunction.

Computer systems that require special consideration regarding safety, for example in applications such asflight control and traffic control, road vehicles, railway interchanges, nuclear facilities, medical equipmentand implanted devices, etc., are called safety-critical systems. The question fundamental to the developmentof safety-critical computer systems is:

Taking into account the typical development cycle of such systems, composed in the simplest case ofthree general stages: requirements specification, design, and implementation, one can look at ways ofaddressing dependability and safety at each individual stage. This is, roughly speaking, how the papers inthis issue are organized.

At the requirements specification stage, the dominating research approach is the use of formal methods,i.e. rigorous mathematical models and techniques for the specification of system properties. Three papers inthis issue represent such research paradigm. Leuchter, Tyszberowicz and Feldman discuss a method and toolto translate specifications expressed in into an equivalent representation in a synchronous language

Special Issue on Dependability and Safety of Real-Time Computer Systems

Dependability andSafety of Real-Time Computer Systems

Dependability

How to achieve and improve dependability and safety?

Verilog

nd

th th

Editorial


Editorial

VOLUME 3, N° 1 2009


21Editorial

VOLUME 3, N° 1 2009

Esterel Veriest

Coq

NuSMV

UML

RTLinux

et al

. Their tool, , is a translator that converts respective designs. Since many libraries of usefuldesigns, such as communication protocols, compression algorithms, are available in Verilog, the large bodyof intellectual-property hardware designs is thus available to be incorporated into a synchronous language.

The second paper of this category, by Olga Tveretina, discusses verification of real-time systems with theproof assistant. She deals with a hybrid automaton as a mathematical formalism for describing hybrid

systems, that is, systems involving the interaction of discrete and continuous dynamics. A framework forreachability analysis is presented, which allows avoiding spurious transactions for certain classes of hybridsystems. Kosęda, Szmuc and Cichalewski use a formal approach in designing automation software for thefree electron laser. They present a method for formal specification and verification of software, based onmodel checking with tool. The tool is used to verify formal properties included in the specification ofsoftware. A dedicated converter translates the model expressed in the specification language into theNuSMV's input language. Definitions of formal properties to be fulfilled by the model are expressed inComputational Tree Logic (CTL).

Formal notations work well only for perfect mathematical models, which are rarely achievable in practice.So, alternative engineering techniques are needed at the design level for more practical solutions. Twopapers addressing such approach are included in this issue, both based on developing more realisticarchitectural models, using the modelling language, specifically the statecharts, to express designsrelated to improving safety. Letia, Barbu and Dinga propose to increase software dependability directlyaddressing the safety issues in road traffic control, by developing a general pre-emptive schedulingalgorithm. It is based on using local priorities to schedule critical resources and global priorities to impactglobal traffic patterns. The simulation results demonstrate that the proposed solution provides robustperformance for relatively low traffic volumes.

The second paper in this category, by Lu and Halang, deals with combining component-based softwarearchitecture models with established fault tolerance techniques. Fault tolerance is often used in researchand practice as a method of improving dependability and safety. It is defined (IEEE Glossary of SoftwareEngineering Terminology) as “the ability of a system or component to continue normal operation despite thepresence of hardware or software faults”. As such, it encompasses special techniques to mitigate or avoidconsequences of faults. The paper presents an architecture described in terms of normal- and abnormal-activity components aiming to support a wide variety of fault tolerance features, and suggest extending UMLto express error detection, error recovery, and redundancy measures to help improve dependability.

The third category of papers involves experiment-based analytical approach to dependability and safetyand is particularly effective at the implementation level. Three papers are included in this category.Gawkowski and his colleagues address the issue of fault sensitivity in two specific classes of control algo-rithms: Dynamic Matrix Control (DMC) and Generalized Predictive Control (GPC). Dependability of both algo-rithms is evaluated using a software-implemented fault injection technique. Tests performed on the controlsystem of a remotely controlled robot vehicle show that the considered algorithms may exhibit unacceptableoutput response, such as slow or oscillatory behaviour, and require exception handling to address these andrelated problems.

Piątek and Grega also analyse the behaviour of a digitally implemented controller for a magneticlevitation device, by studying its speed. Their concern is that the performance of a digital control systemdepends not only on variables, such as the sampling period, control loop execution time, jitter, and generalperformance of individual components, but also on their interaction and cooperation. They propose a newdesign approach based on the relative speed system classification that relies on balancing the closed-loopexecution time and process dynamics. The detailed analysis and optimisation of control algorithmperformance usually involves dealing with the implementation at the operating system level. This is thefocus of the last, but not least, paper in this category. Moryc and ernohorský present an analysis of real-time task jitter under operating system. They describe methods and tools developed to measurejitter, and discuss the results obtained for a data acquisition system. They conclude that the Linux kernelitself significantly contributes to the real-time task jitter, and suggest that employing a CPU designedspecifically for real-time operation could mitigate the effects.

Discussion of dependability and safety of real-time computer systems would not be complete withouttouching one extremely important subject: education. Therefore, we have included a paper on curriculumdevelopment for real-time software-intensive control systems, by Kornecki . The authors report on theinternational activities, involving American, Polish, Czech and French universities, focused on designing andimplementing a coordinated curriculum that would engage students from multilingual, geographically

È

22


separated institutions, and expose them to problems, methods, solution techniques, infrastructure,technologies and tools in the domain of dependable real-time safety-critical control systems. The hope isthat joint efforts will help in creation of international curricula with a compatible quality assurance andassessment process, enabling the mobility of the future workforce and facilitating the career advancement.

We hope that this snapshot of problems and solutions important to dependability and safety of real-timecomputer systems, collected in a single issue, will be of interest to the readers of JAMRIS. Those interestedin this subject more deeply may consider submitting papers to the next edition of the RTS Workshop, whichis planned for the 2009 IMCSIT conference in Mrągowo, on 12-14 October 2009. For details, please seehttp://www.imcsit.org/ or contact the editors of this special issue.

AGH University of Science and Technology, Kraków, [email protected]

Wojciech Grega

Andrew J. Kornecki

Janusz Zalewski

Embry-Riddle Aeronautical University, Daytona Beach, Florida, [email protected]

Florida Gulf Coast University, Fort Myers, Florida, [email protected]

Editorial

Abstract:

1. IntroductionSynchronous languages specify the reactions of reac-

tive and real-time systems to their environment. Theyhave rigorous mathematical semantics, which allowsprogrammers to develop critical software faster and morereliably. Synchronous languages also enable validationand verification of the developed systems. They areparticularly useful for designing the control of real-timeembedded systems [8].

Modern hardware design is done using hardwaredescription languages (HDLs); Verilog [6] is one of thetwo most popular such languages (the other beingVHDL). As a result, there are many libraries of tested andverified Verilog designs available. These include manyuseful applications, such as communication protocols,video and audio compression algorithms, cryptographicalgorithms, and more. These libraries far outnumber

Verilog is one of the two most popular high-level hard-ware description languages. Many libraries of usefuldesigns, such as communication protocols and compres-sion algorithms, are available in Verilog. These designscould be useful to designers of real-time and reactivesystems if they could be translated into the languages usedfor such designs.

Synchronous languages are particularly useful for des-cribing the control of real-time embedded systems. Theirrigorous mathematical semantics allows programmers todevelop critical software faster and more reliably. Synchro-nous languages also enable validation and verification ofthe developed systems.

Veriest is an automatic translator that converts synthe-sizable Verilog designs into the synchronous languageEsterel. The translation into a synchronous language canexpose hidden flaws in the original design, including subtlerace conditions. In addition, the extensive libraries ofverified Verilog designs can now be reused in synchronousdesigns.

Verilog and Esterel have different models and features,complicating the translation. For example, Verilog hasflexible data types and operators for dealing with databuses of varying widths; it also supports three-state logic,which has no equivalent in languages not meant todescribe hardware. Veriest creates functions in the hostinglanguage (usually C) to represent concisely such featuresof Verilog that are not native to Esterel.

Keywords: Automatic transformation, Synthesizable Verilog,Esterel.

corresponding libraries for synchronous languages. Manyof these asynchronous designs could also be useful fordesigners of reactive systems that use synchronouslanguages, if they could be translated into these langu-ages. These could be used to synthesize synchronousdesigns in software as well as hardware. In this way,designers using synchronous languages would be able totake advantage of existing asynchronous libraries ins-tead of having to manually implement (or translate)them synchronously.

Besides allowing reuse of existing designs, trans-lating a Verilog design into a synchronous language canexpose hidden flaws in the design that were not disco-vered by testing. Phenomena such as race conditionsbecome obvious when stated in a synchronous language.

Such translation is complicated by the difference inmodels between Verilog and synchronous languages.Verilog is actually composed of two main sub-languages.

is the subset of Verilog that can bedirectly compiled into hardware. The rest of the languageis used for designing stimulus environments (which arenot a part of the design) for the simulation of synthe-sizable Verilog designs, and contains such features as thegeneration of random test vectors and assertions.Reusable Verilog designs are all written in synthesizableVerilog. This is a hardware-oriented language, and inclu-des variable-length data types and flexible operators forcombining and selecting parts of such buses. Verilog alsosupports three-state logic, in which a wire can be in anundriven (or “floating”) state, enabling multiple sourcesof control for the wire. Such features of the languagehave no equivalent in the target synchronous languages.

We have implemented an automatic translator, calledVeriest, that converts synthesizable Verilog designs intothe synchronous language Esterel [4]. Esterel is one ofthe most popular synchronous programming languages,designed for programming reactive systems. Esterel canbe compiled into sequential code as well as into hard-ware. Veriest preserves the Verilog RTL hardware seman-tics in the generated Esterel code.

In order to create readable Esterel programs, Veriestattempts to keep the structure of the original program asmuch as possible. Some elements of Verilog can be repla-ced by corresponding Esterel elements in a straight-forward manner. These include Verilog's one-bit vari-ables ( ), continuous and procedural assign-ments, conditional controls ( ),values with compatible representations, module instan-tiation, and operators ( ). Features ofVerilog that are not directly expressible in Esterel areimplemented using Esterel's support for external

Synthesizable Verilog

reg, wireif-else, ? :, case

e.g., !=, =

REUSING VERILOG DESIGNS

IN THE SYNCHRONOUS LANGUAGE ESTEREL

Menachem Leuchter, Shmuel Tyszberowicz, Yishai A. Feldman


Special issue 23

functions in the hosting language (usually C). Veriestdefines a set of auxiliary functions, derived from the par-ticular features and operations used in the source design.The function names follow a fixed scheme, so that theirsemantics can be immediately understood without refe-rence to their implementation. In this way, implemen-tation details are hidden while the design is still exe-cutable. The Verilog elements that have been handled inthis way are vectors (including partial vectors), arrays,operations that depend on variable width (e.g., ongroups of bits), concatenation, and tri-state signals.

We have successfully translated a number of differentVerilog designs using this tool. The generated Esterelcode was about half again as long as the original code(excluding the generated C functions). The original in-tent was quite clear in the generated code, and it seemedto be understandable and maintainable. This is due to thefollowing aspects of the translation: (1) the original codelayout and variable names were preserved; (2) wheneverpossible, Verilog constructs were translated directly tothe corresponding Esterel constructs; (3) the complexityinherent in the other part of the translation was hiddenunder a suitable abstraction that uses a lucid namingscheme.

Esterel is a high-level synchronous language that sup-ports abstraction, a variety of data types and the abilityto define new ones, and interoperability with other lan-guages. It contains special constructs for timing control,and is therefore appropriate as the target language fordeveloping reactive systems.

In contrast, Verilog is meant for hardware design, andthe synthesizable subset of Verilog lacks many of theabstraction mechanisms and data types of Esterel. It doesemphasize timing, although in an asynchronous setting,and in that sense is closer to Esterel than most con-ventional programming languages. The translation of C/ -C++/Java code into Esterel is not as useful as that re-sulting from Verilog, since the former programs are se-quential, and have no timing restrictions or concurrency.The loss in such languages of the synchronization charac-teristics in the design makes it less suitable for a synchro-nous language such as Esterel.

Some features of Verilog can be translated more-or-less directly into Esterel , although care must be taken topreserve the semantics. Other features pose more diffi-culties. Verilog supports arbitrary-width variables, withtheir associated operations. For example, it is possible todefine 5-bit variables, and arithmetical and shift opera-tions on such variables truncate any results to 5 bits.Similarly, it is possible to define a variable consisting of128 bits, which is beyond the capabilities of Esterel'sbuilt-in data types.

Verilog also supports flexible combinations of parts ofsuch variables. For example, the expression

represents the value containingthe seven least-significant bits of with thevalue of concatenated on the right. Inhardware, such operations correspond to simple wiring,without computational content. In Esterel, these have tobe represented in code.

1.1. The Gap

#

{data_out[6:0], data_in}

data_outdata_in

Hardware designs sometimes usesignals, which are distinct from logical high and low

(or one and zero) values. The floating signals are notactively driven, so that any of a number of connectedcircuits can drive them in turn. This is useful in caseswhere one output value can result from one of severalsources, each active at a different time, or when a singlewire is used alternatively for input and for output. Verilogfully supports tri-state signals; for example, the expres-sion denotes a 6-bit value whose most-significant bits are 101, followed by three floating bits.These bits could be supplied by a different module.Esterel has no built-in support for tri-state values.

In addition, Esterel has no built-in support for arrays,a basic data type of Verilog (and many other languages).These have to be simulated in the generated code.

Those constructs of Verilog that have direct counter-parts in Esterel are translated separately and indepen-dently. Note that even seemingly trivial operations suchas addition are complicated by the presence of data typeswith flexible widths. For example, the Verilog expression

cannot be directly translated to Esterel if the origi-nal and are 5-bit variables, whereas their counter-parts in Esterel are integers, since truncation of the sumto 5 bits needs to be added.

Unique Verilog constructs require a more detailedanalysis of the Verilog source code. There are generaltranslation solutions for each such construct, butthese are sometimes overly complex. Veriest thereforeattempts to recognize some frequently-used Verilogpatterns, in order to translate those into more conciseand efficient code.

Pure Esterel can express some Verilog featuresawkwardly, and others not at all. For example, it isimpossible to represent in Esterel a 128-bit vector usingthe built-in types. Five-bit vectors be representedusing Esterel integers, but correctly translating opera-tions on them to pure Esterel requires additional opera-tions that increase code size and obscure its meaning. Toachieve a full and efficient translation we use Esterel

[1]. These types are considered completely abstractby Esterel itself; their implementation is given in thehost language. Veriest defines a set of user types withassociated operations. The types and operations gene-rated depend on the particular source program; however,they follow common patterns, and their names comp-letely describe their semantics. Designers who want tomaintain and modify the generated Esterel code there-fore do not need to read the C implementation at all.

We start with a small yet complete example, and thendiscuss the non-trivial issues involved in the translationone by one. The full details are available in [5].

Figure 1 contains a Verilog design of a simple 24-bitup-down counter. Its inputs are a clock, a counting direc-tion selector line ( ) and a reset line ( ). Itsoutputs are a 24-bit bus that stores the current value anda carry for the next stage. The value of is

tri-state (or floa-ting)

can

usertypes

6'b101zzz

a+ba b

dir rst

data_out

2. The Translation


Special issue24

VOLUME 3, N° 1 2009

# In most of this paper we refer to Esterel version 5, whichwas the latest version when this work was implemented [5].We address the changes to Esterel in Section 3.1.

incremented or decremented at each rising clock cycle,depending on whether the value of is one or zero,respectively. Whenever overflows orunderflows, it is truncated, and is set to one forone clock cycle.

dirdata_out

carry

Figure 2 shows the Esterel code generated by Veriestfrom the Verilog design. Both Verilog wires (transientvalues without memory, such as and ) and regi-sters (memory devices, such as ) are translatedinto Esterel as signals with boolean values. A change inthe variable value causes the corresponding signal to beemitted, while the value of the variable is stored in thesignal's associated value. A binary value could have beenrepresented by the presence or absence of a signal. How-ever, the use of a signal with a value preserves two impor-tant characteristics of Verilog register variables: first,retaining the value after the signal disappears, andsecond, the ability to refer to the value of the signal atthe previous clock tick even while a new value is assignedto it. This capability is crucial for correct translation.Because of the need to refer to previous values, allsignals are generated with appropriate initializations.

The Verilog design uses ,which have a triggering condition. In this case, thetriggering condition is

, which means that this section of codeis activated on a positive edge of the signal or

clk dircarry

always @(posedge clk ornegedge rst)

clk

procedural assignments

module up_down_counter(data_out,carry,rst,clk,dir);

input clk,rst,dir;

output [23:0] data_out;

output carry;

reg [23:0] data_out;

reg carry;

always @(posedge clk or negedge rst)

begin

if (!rst) begin data_out <= 0; carry <= 0; end

else

begin

if (dir)

begin

data_out <= data_out + 1;

if (data_out == 24'hffffff) carry <= 1;

else carry <= 0;

end

else

begin

data_out <= data_out - 1;

if (data_out == 0) carry <= 1;

else carry <= 0;

end

end

end

endmodule

Fig. 1. A Verilog design of an up-down counter.


Special issue 25

VOLUME 3, N° 1 2009

module up_down_counter:

type VEC_23_0; % definition of new type for 23-bit register

function CONV_STRING_VEC_23_0(string):VEC_23_0;

function PLUS_VEC_23_0(VEC_23_0, VEC_23_0, integer):VEC_23_0;

function COMP_EQ_VEC_23_0(VEC_23_0, VEC_23_0): boolean;

function MINUS_VEC_23_0(VEC_23_0, VEC_23_0, integer):VEC_23_0;

input clk:=false: boolean, rst:=false: boolean, dir:=false: boolean;

output data_out:VEC_23_0, carry:=false: boolean;

loop % procedural assignment section

await [clk or rst];

if (((?clk) and not pre(?clk)) or (not(?rst) and pre(?rst))) then

if (not pre(?rst)) then

emit data_out(CONV_STRING_VEC_23_0("0"));

emit carry(false);

else if (pre(?dir)) then

emit data_out(PLUS_VEC_23_0(pre(?data_out), CONV_STRING_VEC_23_0("1")), 24);

if (COMP_EQ_VEC_23_0(pre(?data_out), CONV_STRING_VEC_23_0("16777215")))

then emit carry(true);

else emit carry(false);

end if;

else

emit data_out(MINUS_VEC_23_0(pre(?data_out), CONV_STRING_VEC_23_0("1")), 24);

if (COMP_EQ_VEC_23_0(pre(?data_out), CONV_STRING_VEC_23_0("0")))

then emit carry(true);

else emit carry(false);

end if;

end if;

end if;

end if

end loop

end module

Fig. 2. The Esterel version of the up-down counter.

a negative edge of . This is translated into an Esterelloop that waits for a change in or . Becausethese are signals with values, the meaning of thestatement is to wait for the

of either signal, regardless of their values.A signal exists when a value is emitted for it. The type ofchange (from false to true, denoting a positive edge, orfrom true to false, denoting a negative edge) is checkedseparately, with the following statement. This isnecessary because Esterel does not support the notion ofpositive or negative edges of signals, and is the reasonfor the need to reference previous values. This treatmentof signals with values whose existence indicates theassignment of new values allows the Esterel compiler togenerate

The body of the Verilog statement uses anumber of , expressed using the

operator. The right-hand sides of all concurrent non-blocking assignments are computed before any value ischanged. In the generated Esterel code, the same effectis achieved by using the previous values of the variableson the right-hand side. Thus, the two Verilog nonbloc-king assignments ; would be translatedintowhereas the (sequential) blocking assignments

would be translated into.

Other than these changes, the structures of the twoprograms are similar. The most striking change is thetreatment of the 24-bit data type used for .In Verilog, the definitioncauses the addition operator in todenote 24-bit addition, which truncates its result to therequired length. To achieve the same result in Esterel,Veriest defines a user type called . All therequired operations on this data type are defined as userfunctions. This particular program uses addition andsubtraction on 24-bit quantities, and compares themfor equality. Veriest therefore defines the functions

for these operations. The im-

rstclk rst

await [clk or rst]

if

always

<=

a <= b; b <= cemit a(pre(?b)); emit b(pre(?c));

a = b;b = c; emit a(?b); emitb(?c);

data_outreg [23:0] data_out

data_out + 1

VEC_23_0

PLUS_VEC_23_0, MINUS_VEC_23_0, andCOMP_EQ_VEC_23_0

existence

(a) Verilog source

(b) Esterel translation

Fig. 3. Translating continuous assignments.

nonblocking assignments

more efficient code, which only checks theconditions when the value is assigned, rather than ateach instant.

assign o1 = a | b;

assign b = a;

loop

await [a or b]; emit o1(?a or ?b);

end loop

||

loop

await a; emit b(?a);

end loop;

plementation of these functions in C is straightforward,and is generated automatically.

This example also shows the treatment of constants.In this example, the target host language could representintegers of up to 16 bits. The 24-bit vectors of theexample are therefore represented as a struct of twointegers, and there is no general way to specify constantsof this type. The general solution in such cases is to usestrings to encapsulate the constants, with conversionfunctions (like ) to createthe internal representation. Of course, wheneverpossible, numeric constants are used.

In addition to the proce-dural assignments shown in the example, Verilog alsosupports statements of the form

. Their semantics is that thevariable always has the value of the expression; wheneverthe value of the expression changes, so does the value ofthe variable.

In order to translate continuous assignments intoEsterel, they must be placed in a loop that waits on anyvariable involved in the expression to change. If there aremultiple continuous assignments, they are translatedseparately into parallel Esterel loops. Figure 3 shows anexample of such translation.

There are two possible waysof dealing with variable-width vectors. The first is to em-bed them into the closest built-in integer type largeenough to hold them. This makes arithmetical operationsrelatively straightforward, but selecting subfields andcombining them to create new vectors is more difficult.The second approach is to keep each vector as a set ofseparate bits. This makes selection, shifting, and conca-tenation easier, but arithmetic becomes complex. Quiteoften, the same variable participates in both types ofoperations. Veriest takes the first approach. Each of thenew types created for variable-width vectors is embeddedin the next highest integer type or in a C struct of integersin case the field is too wide. As shown above, special-purpose functions are created as necessary in order toperform arithmetical operations on the new types. Simi-lar functions are created for selection and concatenation.

A set of concatenation functions is created whenvariable-width vectors are combined. For example, thestatement couldbe translated into

,where the second and fourth arguments specify thenumber of bits to take from the preceding argument.However, Veriest recognizes this pattern as a shift, andproduces the more concise

. The second argument to the shift function is thewidth of the shifted field, and the third is the shiftamount.

Veriest recognizes the “shift” pattern when the samevariable appears on both sides of an assignment, withsome bits from either end of the vector omitted but allother bits shifted, and when another value takes theplace of the missing bits. For example, this pattern willalso be recognized in the statement

, but not in

CONV_STRING_VEC_23_0

assign

data[7:0] = {data[6:0], a}emit data(CONCAT_INT_BOOL

(CONV_INT_INT(?data, 6, 0), 7, ?a, 1))

emit data(OR_INT_BOOL(SHIFT_L_INT_INT(?data, 7, 1),?a))

data[7:0] ={data[6:2], a, b} data[7:0] =

Continuous Assignment.

Variable-Width Vectors.

continuous assignmentvar = expression


Special issue26

VOLUME 3, N° 1 2009

{a, data[6:0]}data[7:1] = {data[6:2], a}data

= COMP_EQ_VEC_8_0

reg [7:0] mem[0:255]

ARRAY_REG_7_0_255_0

_Z

datadata_Z

data data_Zselect

datadata

data_Z

COMP_EQ_Z and COMP_NEQ_Z

, since the data is not shifted, nor in, since not all bits

of are assigned.Such heuristics are not necessary for correct trans-

lation, but they improve code readability and reduce itssize. Since the goal of the translation is to generatemaintainable code in the synchronous language, it isimportant to include such heuristics for common cases,such as shifts. For the same reason, built-in Esterel ope-rators are used when possible. For example, Veriest willuse “ ” instead of the function .

Verilog supports arrays of other types, and inparticular arrays of registers. For example, the declara-tion defines an array con-taining 256 8-bit vectors. (This is a typical way to definememory.) Esterel, on the other hand, does not have built-in arrays. As in the case of vectors, the solution is to useuser types. In this example, Veriest will create the type

, with associated operationsfor reading and writing elements or ranges of arrays.

As mentioned in Section 1.1, Verilogsupports a floating state for bits in addition to zero andone. In Esterel, it must be simulated using an additionalbit. For each variable that may have floating bits, Veriestcreates another variable that has the same name witha suffix. Each bit in the new variable has the valueone exactly when the corresponding bit in the originalvariable is in the floating state. Veriest creates code tomanage both variables together in order to represent theVerilog semantics. For example, the Verilog excerpt

is translated into

In this case, the variable is shared between allmodules that may attempt to write to it, but isduplicated for each module. A module may only write to

if it asserts in that those bits it is writingto are not floating. Note that when is false andall bits of are set to tri-state mode in the Verilogsource, there is no need to change the value of thevariable in Esterel, since its value is irrelevant when

is set to all ones.Veriest creates special comparison functions, such

as , for comparingtri-state variables.

Arrays.

Tri-State Logic.

inout [2:0] data;

data = (select) ? 3'b111 : 3'bzzz;

inputoutput data: integer;

output data_Z: integer;

if (?select) then

emit data(7); % set data to 3'b111

emit data_Z(0); % set data to normal mode

else

emit data_Z(7); % set data to tri-state mode

end if

3. Results and discussionWe have evaluated Veriest on four designs. These are

all real and useful Verilog designs, each written by a dif-ferent programmer. The example designs include the fol-

lowing: the up-down counter shown in Section 2;a Viterbi encoder, an error-correcting algorithm based onconvolution encoding [7]; a real-time clock; and animplementation of the I C protocol for connecting multi-ple devices using only two wires. In all cases, the gene-rated code was functionally equivalent to the original.This section analyzes the results of the translation ofthese examples, and discusses their implications.

Esterel code generated by Veriest tends to be longerthan the original Verilog code; the average increase in ourexamples was 60% (excluding the generated C functions).Generated lines also tend to be longer, due to the substi-tution of primitive operators such as arithmetic, selec-tion, shifting, and concatenation, by generated functionswith relatively long names. Nevertheless, most lines havea reasonable length.

There are several other factors for the increase in thetotal size of the code. The largest overhead in thetranslation comes from continuous assignments, each ofwhich needs to be translated into a loop. This is mostlydue to the need to separate the triggering condition intotwo parts, one in the statement listing the signalsto watch, and the other in the statement that checksthe particular triggering values. Another source for theincrease in size of the generated code is the differencebetween the control structures in the two languages. Forexample, Esterel lacks a or statement;Verilog's statement is therefore translated intonested s. A very common construct in hardware designsis a state machine, which is often implemented as a long

statement. Translating that statement into anresults in many terminating statements, whichincrease code size and decrease readability.

In spite of all these factors, the increase in the totalsize of the code seems quite reasonable. The structure ofthe original design is preserved in the translated design tothe best degree possible, including all module, register,and wire names. The original intent is therefore easilydiscernible in the generated design, making it easilymaintainable.

As explained above, Veriest translates part of thesource Verilog design into Esterel, and part into thehosting language, C. The decision of what features totranslate into which language was based on two criteria:

1. whatever can be stated concisely in Esterel should berendered in Esterel;

2. host-language functions should have clear and simplesemantics and a short and efficient implementation.

Indeed, the meaning of the host-language functionsis immediately obvious from their names. The consistentand simple naming scheme means that the Esterel desig-ner need not see the C implementation; all the informa-tion required to understand and maintain the design isavailable in the Esterel source code. Also, host functionsare only used when there is no equivalent Esterel

2

#

3.1. Maintainability

awaitif

case switchcase

if

case ifend if


Special issue 27

VOLUME 3, N° 1 2009

# The transformations were designed to preserve the Verilog RTLhardware semantics. We also ran simulations of the source and targetprograms to check their equivalence.


Special issue28

construct. For example, the comparison functions (likethe family) will not be used when the built-inEsterel comparison operator will have the same effect.

Tools that compile Esterel into sequential code orhardware could also be made to take advantage of thesimple and consistent naming scheme in order to produceefficient results.

Since the publication of the first author's thesis [5](on which this paper is based), the Esterel language(currently at version 7) has been enhanced with new datatypes and operators. These include bitvectors (arrays ofbooleans), bitvector maps (records composed of fieldsand bitvector slices), encoders from unsigned expressionsto bitvectors, and signal arrays. These were added to thelanguage to support “hardware or low-level softwaredesigns” [3]. These changes remove the need to use auxi-liary C functions to implement operations previously una-vailable. The translation can now be even more conciseand readable.

Because of the asynchronous nature of the language,it is possible to write in Verilog designs that have raceconditions. These are not flagged by the compiler, andmay not be caught during simulation. Figure 4(a) showsa simple example of a race condition [2]. In this example,a signal sets to 0 and to 1. A subsequentsignal causes a race condition, where the firstblock tries to set to the value of while the secondblock simultaneously tries to set to the value of .However, the Verilog simulator will execute one blockbefore the other; both orders are legal. The result will bethat both and will have the same value: 1 if the firstblock is executed first, and 0 if the second block executesfirst.

The Veriest translation of this example to Esterel isshown in Figure 4(b). Because of the synchronous seman-tics of Esterel, this program is illegal and the compilerrejects it with the error message “statically cyclic prog-ram, cannot be compiled by scssc.”

In this simple Verilog example, the race condition iseasy to spot by inspection. However, subtle race condi-tions in larger Verilog designs will be harder to discover.Simulation, and even hardware execution (for differentreasons), may yield correct results even in the presence ofrace conditions, and the problem might manifest itselfonly under rare conditions that are difficult to duplicate.The translation to the synchronous language discoversthese problems during compilation.

We have presented Veriest, a translator that can con-vert designs in synthesizable Verilog into the synchronouslanguage Esterel. This makes the large body of intellec-tual-property hardware designs available to be incorpo-rated into synchronous designs. As an added benefit, thetranslation of an asynchronous design into a synchronouslanguage can help discover subtle timing conditions thatmay have escaped testing in an asynchronous setting.

The translation is complicated by several hardware-related features of the source language. These are solvedby using user types implemented in the host language.

COMP_EQ

rst x y clkalways

x yy x

x y

3.2. Discovering Race Conditions

4. Conclusions

The structure of the resulting translation is very close tothat of the original, although it is somewhat more ver-bose. Experiments have shown that the results are stillreadable and maintainable in the target language.

Some Verilog designs are more appropriate thanothers for automatic translation to a synchronous lan-guage. Designs of large generic processing componentssuch as CPUs and DSPs will probably not generate usefulsynchronous designs. The same effects can be betterachieved by coding directly in Esterel. On the other hand,hardware-oriented protocols for specific purposes, suchas communication protocols and compression algorithms,are good candidates for automatic conversion and areexpected to yield results comparable to our examplecases.

(a) A Verilog design with a race condition [2].

(b) The translation to Esterel.

Fig. 4. A race condition.

module race(x, y, clk, rst);

output x, y;

input clk, rst;

reg x, y;

always @(posedge clk or posedge rst)

if (rst)

x = 0;

else

x = y;

always @(posedge clk or posedge rst)

if (rst)

y = 1;

else

y = x;

endmodule

module race:

input clk:=false:boolean, rst:=false:boolean;

output x:=false:boolean, y:=false:boolean;

loop

await [clk or rst];

if (((?clk) and not pre(?clk))

or ((?rst) and not pre(?rst))) then

if (?rst) then emit x(false); else emit x(?y);

end if;

end if

end loop

||

loop

await [clk or rst];

if (((?clk) and not pre(?clk))

or ((?rst) and not pre(?rst))) then

if (?rst) then emit y(true); else emit y(?x);

end if;

end if

end loop

end module

VOLUME 3, N° 1 2009


Special issue 29

AUTHORSMenachem Leuchter

Shmuel Tyszberowicz*

Yishai A. Feldman

References

- Computer Science Department,The Open University, Rabutzki Str. 108, 43107 Raanana,Israel.

- School of Computer Science,The Academic College of Tel Aviv Yaffo, 61083 Tel Aviv,and Tel Aviv University, 69978 Tel Aviv, Israel. Phone:+972-3-6803398, Fax: +972-3-6803342.E-mail: [email protected].

- IBM Haifa Research Lab, HaifaUniversity Campus, Mount Carmel, 31905 Haifa, Israel.* Corresponding author

[1] G. Berry and G. Gonthier, “The Esterel synchronous pro-gramming language: Design, semantics, implementa-tion”, , vol. 19, no. 2,1992, pp. 87-152.

[2] C. E. Cummings, “Nonblocking assignments in verilogsynthesis, coding styles that kill!”. In:

, 2000.[3] Esterel Technologies. The Esterel v7 reference manual.

http://www.esterel-technologies.com/files/Esterel-Language-v7-Ref-Man.pdf.

[4] N. Halbwachs,, Kluwer, 1993.

[5] M. Leuchter. Translating Verilog designs into thesynchronous language Esterel. Master's thesis, TheOpen University, Israel, February 2003.http://telem.openu.ac.il/cs/msc/files/ leuchter.pdf.

[6] S. Palnitkar, ,Prentice Hall, 1996.

[7] J. G. Proakis, D McGraw-Hill, 3edition, 1995.

[8] R. Shyamasundar and J. Aghav, “Realizing real-timesystems from synchronous language specifications”,

, Work in Progress Session,Orlando, Florida, USA, 2000.

Science of Computer Programming

Synopsis UsersGroup (SNUG)

Synchronous Programming of ReactiveSystems

A Guide to Digital Design and Synthesis

igital Communications,

Real Time Systems Symposium

rd

VOLUME 3, N° 1 2009

Abstract:

1. Introduction

Hybrid systems involve the interaction of discrete andcontinuous dynamics. Hybrid systems have been used asa mathematical model for many safety critical applica-tions. One of the most important analysis problems ofhybrid systems is the reachability problem. In this paper weargue that the proof assistant Coq can be used for thehybrid systems verification. An example of a train crossingcontrol is provided.

Keywords: Formal methods, real-time, theorem proving.

Real-time embedded systems have become very impor-tant in our everyday life. Programs such as device driversand embedded controllers must run on real-time cons-traints. Demand placed on the embedded systems functio-nality, complexity and critical nature are increasing.

Hybrid systems are systems where is a significantinteraction between the continuous and discrete partsand high performance specifications are to be met by thesystem. For example, hybrid systems arise from the inter-action of discrete planning algorithms and continuousprocesses.

Many of the hybrid systems applications are criticalsafe and require the guarantee of safety operation. Theproblem of safety verification seeks for an answer to thequestion: is there a potentially unsafe state reachablefrom an initial state? Therefore, formal verifying safetyproperties of a hybrid system consist of building a set ofreachable states and checking whether this set intersectswith a set of unsafe sets. Therefore, one of the mostcentral problems in the analysis of hybrid automata is theproblem. It checks whether all trajectories of a givenhybrid system meet a given safety requirement. For sys-tems with continuous dynamics it is very difficult tocompute the set of all states reachable from an initial set.

Abstraction is one of the complexity reduction tech-niques. It reduces the state space of a system by mappingit to an abstract set of states that preserve the actualbehaviour of the system. A predicate abstraction appro-ach for the verification of hybrid systems is representedin [2]. However, the computational cost of predicateabstraction can be too high, and for large systems prac-tically infeasible. That is why we start from a method thatdecomposes the state space of a system according a rec-tangular grid [6]. We show applicability of our methodwith the verification example that we have formalizedwithin the proof assistant. It models the gate controllerof a railroad crossing.

2. Problem descriptionWe use a hybrid automaton as a mathematical formula

for describing hybrid systems. We formally define thenotion of hybrid automaton. The notion of a hybridautomaton was introduced in order to extend verificationmethods towards the systems with continuous anddiscrete dynamics [1]. For simplicity, we have assumedthat the number of discrete locations is finite and thevector field is Lipschitz continuous. It guarantees thatthe solutions of the differential equations are welldefined.

A Hybrid automaton is a tuple , ,, , , , and with the following

components:

(Admissible function) We say that a functionis admissible if there are and such that

for all , , such thatfor some there is such that

.In the following we assume that functions defining

continuous behaviour satisfy this property. It will beused for the proving of the correctness of the approach.

Definition.

Definition.

HS = (DS nS Inv F Guard Reset)

f:

0

�

�

�

�

�

is a finite set of discrete locations; is thedimension . The state space of is

. Each state has thus the form , whereand . is a set of initial states.

assigns to each discrete locationan invariant set, which constrains the value of thecontinuous part while the discrete part is , i.e.continuous evaluation can go on as long as remainsin .

describes a guard condition,i.e. if a system remains in a discrete location and acontinuous state x reaches the guard ( , )then the discrete state may change its value to .

is a vector field.is a reset function.

A system state can change in two ways: either conti-nuously by time evaluation or by discrete transitions.Hence, there are two kinds of transitions. First one isa continuous transition, describing the evolution of a sys-tem in a given location. Second one is a discrete transi-tion, describing movement from one location to anotherlocation and, possibly, changing the continuous variablesaccording to the function Reset. Based on this, the se-mantics of a hybrid automaton is given by the followingtransition system [2].

DS nHS HS S = DS ×

R (l,x) l DSx R S S

Inv: DS P(R ) l

lx

Inv(l)Guard: DS × DS R

lGuard l l

lF: DS × R RReset: DS × DS × R R

R R m mx x x R x m x m x

m mx m x m x

>0

n

n

n

n

n n

n n

n n

n

�

� �

�

�

�

�

�

0

1

1 2

2

1 2

1 2 3 1 1 2 1 3

1 2

1 2 2 2 3

�

�

�

= + (1- )0 < < 1 0 1

f( ) = f( ) + (1- ) f( )

3. Transition system

TOWARDS THE SAFETY VERIFICATION OF REAL-TIME SYSTEMS

WITH THE COQ PROOF ASSISTANT

Olga Tveretina


Special issue30

Definition.

Definition.

Definition.

Definition.

(Transition System) Given a hybrid automaton, , , , , , , the transition

system of consists ofthe set of states ;the set of initial states ;two relations and satisfying the following

(Trajectory) Given a hybrid automaton ,a trajectory of is a sequence , such thatfor all i and j such that or .

Given a hybrid automaton and a set of unsafe sta-tes , the safety verification problem concerns with pro-ving that all trajectories of cannot enter .

Our method is based on the approach that decomposesthe continuous state space according to a n-dimensionalrectangular grid. Such abstractions are mostly performedin a manual manner. In general, a state space can berepresented by polyhedra [2]. This is a more flexibleapproach but it requires an algorithm for dealing withthese polyhedra. A rectangular grid is less flexible but it issimpler to implement the corresponding operations.

We assume that we have an algorithm that can pro-duce a decomposition of a state space. We denote bya set of all abstract states. In order to define a discreteabstraction of a given system, we have to describe thetransitions between the abstract states, the set of initialabstract states , and the set of abstract unsafe states

. Given a hybrid automaton and a set of abstractstates, the set of initial abstract states can be computed.An artificial transitivity can create many false counterexamples, i.e. abstract behaviours that do not correspondto any concrete ones. That is our incentive to optimise anabstract transition system from [2] by reformulating therelation defining an abstract continuous step.

(Abstract Transition System) Given a hybridautomaton , , , , , , , theabstract transition system of

consists ofthe set of abstract states ;the set of initial abstract states ;two relations and satisfying the following

(Abstract Trajectory) Given a hybrid automa-ton and a set of abstract states , an abstracttrajectory of is a sequence , such thatfor all i and j such that or .

Note, that in general, an abstract trajectory startingfrom some initial abstract state is not unique.

HS = (DS n S Inv F Guard Reset)Tr = {S, , , S } HS

SS

(l,x) (l,y) t 0, i, F (l,x ,t)=y y Inv(l),

where x=(x , ... ,x ), y=(y , ... , y )

(l,x) (l', y) (l,x) Guard(l, l') y=Reset (l,l',x)

HSHS s , s , …, s

i>j, s s s sHS

UHS U

S

SU HS

HS = (DS n S Inv F Guard Reset)Tr = {S , , , S }

HSS

S

(l,x ) (l,y ) x x , y y : (l,x) (l,y)

(l,x ) (l', y ) x x , y y : (l,x) (l', y)

HS SHS s , s , …, s

i>j, s s s s

0

0

0

1 1

1 2

0

0

0

0

1 2

� �

� �

� � � � � �

� � �

� �

� �

� �

� � � � �

� � � � �

� �

c d

c d

c i i i

n n

d

m

j d j j c j

c d

c d

c c

d d

m

j d j j c j

�

�

�

�

�

�

4. Reachability analysis

a

a

a

a a a a a

a

a

a a

a a a a a

a a a a a

a

a a a

a a a a

5. Modelling of hybrid systems withthe proof assistant CoqCoq is an interactive proof assistant, which allows

formal defining mathematical objects and helps the userwith proving the properties of these objects. Basically,the use of Coq follows three steps: a) define the objectsand axioms used, b) state a theorem, c) provide proofsteps until the proof is completed. For more details werefer to [3].

We do not have enough space to present allformalizations in Coq that is why we present only a smallpart of it.

Definition DiscStates:=Set.An abstract state is defined as a list of natural numbers.Definition AbsState := list nat.A partition of an abstract state is defined as a list of listsof naturals.Definition Partition:= list (list nat).Some other ingredients are defined as follows.Parameter Invariant: DiscStates AbsStates.Parameter Guard: DiscStates DiscStates AbsStates.Parameter Flow: DiscStates AbsStates AbsStates.Parameter Reset: DiscStates DiscStates AbsStates

AbsStates.

As an example we consider, the gate controller ofa railroad crossing from [4]. The model consists of twosubsystems: a train and the gate controller. The train isrequired to send a signal at least two minutes beforeit enters the crossing. The train sends a signal when itleaves the crossing and it must happen no afterwards than5 minutes after the signal (this is expressed by theguard ). The gate must be closed in at least 1minute after the signal is received and not later thanin 2 minutes (the guard is ). The gate responds byopening within 1 minute after receiving the signal.We have considered a product of timed automata thatcombines the train process and the controller process,and the resulting system is depicted in Figure 2. It has thefollowing discrete locations: Loc1: a train is far from thegate and the gate is open; Loc2: the train is approachingthe crossing and the gate is open; Loc3: the train isapproaching the crossing and the gate is closed; Loc4: thetrain has left the crossing and the gate is closed. We wantto verify that the gate is never closed longer than 5 minu-tes. There are two continuous variables. Therefore, thedimension of the continuous state space is 2.

Definition Dim := 2.There are four discrete states. That is modelled in Coq asfollowing.Inductive DS: Set := | D1: DS | D2: DS | D3: DS | D4: DS.The partition of the continuous state space is:Definition P := (0::1::2::3::4::5::6 )::(0::1::2::3::4::5::6).

We were able to 'model check' that unsafe states arenot reachable. The full formalization of the verificationapproach includes also a proof of the correctness of theprocedure in Coq that will use a definition of an admissi-ble function. Due to the property described in the defini-tion, a segment of a straight line is mapped to a segment

�

� �

� �

� �

�

appout

appx

appy

out

2< <5

1< <5


Special issue 31

of a straight line. This means that for each continuousstate that is in some abstract state there is a correspon-ding abstract transition. This proof is left for future work.

We have made a first step towards the fully formalverification of hybrid systems in the proof assistant Coq.The presented framework allows combination of discreteabstraction with other approaches, as "barrier certifica-tes" for example. The train-crossing example was "modelchecked" in Coq. As for future work, we intend to inves-tigate the structure of special classes, for example linearhybrid systems, for which our method is efficient.

- Institute for Computing and Informa-tion Sciences, Radboud University Nijmegen, The Nether-lands. E-mail: [email protected].

6. Conclusions and future research

ACKNOWLEDGMENTS

AUTHOROlga Tveretina

References

I am grateful for the support by Milad Niqui in the field of Coq,and for the support by Herman Geuvers and Dan Synek for theexamples of hybrid systems formalizations in Coq. The researchis supported by the BRICKS/FOCUS project 642.000.501.

[1] R. Alur, C. Courcoubetis, N. Halbwachs, T. A. Henzinger,Pei-Hsin Ho, Xavier Nicollin, A. Olivero, J. Sifakis, S.Yovine, “The algorithmic analysis of hybrid sys-tems”,

, vol. 138, 1995, pp. 3-34.[2] R. Alur, Th.Dang, F.Ivancic, “Reachability Analysis of

Hybrid Systems via Predicate Abstraction”,, 2004.

[3] Y. Bertot, P. Casteran, “Interactive Theorem provingand Program Development”, Springer, 1998.

[4] T.A. Henzinger, X. Nicollin, J. Sifakis, S.Yovine, “Sym-bolic Model Checking for Real-time Systems", 7

, 1992.[5] A. Henzinger, P.W. Kopke, A. Puri, P. Varaiya, “What's

Decidable About Hybrid Automata?”,, vol. 57, no. 1, 1998, pp. 94-124.

[6] S. Ratschan, Z. She, “Safety verification of hybrid sys-tems by constraint propagation-based abstraction refi-nement”,

, vol. 6(1), 2007.

Theoretical Computer Science

ACM trans-actions on embedded computing systems (TECS)

Sympo-sium of Logics in Computer Science

Journal of Compu-ter and System Sciences

ACM Transactions on Embedded ComputingSystems (TECS)

th


Special issue32

Abstract:

1. IntroductionThe peculiarity of this system implies a number of

requirements typical for [15].The automation software for supervision of the laserequipment cannot break it due to its internal logicalerror. It also must not expose human personnel inspec-ting high power laser equipment to a risk of beinginjured. One of the most important requirements forcustomer-oriented facility as FLASH [1] is maximizationof (the time when the FLASH is utilizedfor the experiments). The automation software is expec-ted to be a means for improving this factor by reducing

and by providing automatic fault recovery.Under these circumstances of the software seemsto be very important too.

Several attempts to automate certain subsystems ofthe FLASH have been performed at the DESY [3,4,5,6].All of them utilized the DOOCS [2] Finite State Machine[7,3] toolkit or Stateflow [8]. Authors' practice revealsthat successful applications of simple automation sche-mes are feasible but design of statemachines for largersubsystems turns out to be tedious and error-prone. Theproblem becomes particularly evident when specificationevolves and design has to be updated. Then, even wellelaborated statemachine becomes a mixture of complexexpert's knowledge and tricky endeavours, which "make

Free-electron laser FLASH (260-meter-long machine) isa pilot facility for the forthcoming XFEL (3 km). Along withgrowth of the experiment, service and maintenance arebecoming so complex that certain degree of automationseems to be inevitable. The main purpose of the automa-tion software is to facilitate operators with computer-aidedsupervision of several hardware/software subsystems. Theefforts presented in this contribution concern elaborationof general framework for designing and development ofautomation software for the FLASH. The toolkit facilitatesspecification, implementation, testing and formal verifi-cation. The ultimate goal of the framework is to systema-tize the way of automation software development and toimprove its dependability. At present usefulness of thetools is being evaluated by testing the automation soft-ware for single RF-power station of the FLASH.

safety-related applications

machine uptime

human errorliveness

Keywords: Automation, formal methods, model checking,expert system, Prolog, FLASH.

1

2

it work". Both aforementioned toolkits offer merely theimplementation tools. They do not facilitate stages ofspecification, testing and verification.

To address requirements of application domain, seve-ral mechanisms borrowed from expert-systems field havebeen used. Proposed software consists of two executionengines (see Fig. 1) supplied with the specification in thedomain-specific language. The planner engine assemblesplans to drive the subsystem automatically towardsdesired operation mode. The exception handler is desig-ned to deal with possibly complex exceptional situations,which may be exposed by driven hardware. Its role is tofix known operation glitches and perform conflict resolu-tion in case of multiple exceptions

Single installation of the automation software con-sists of two runtime automation engines and two speci-fication files. Cooperation of the engines is realized bya dedicated cooperation protocol.

Its role is to automate routine operation proceduresusually performed by the operators. It consists of speci-fication language interpreter, state estimator, plannerand plan executor. State estimator retrieves current sta-tus of supervised accelerator subsystem. Planner synthe-sizes a sequence of procedures bringing the system fromactive state to the state satisfying specification of targetoperation mode. Plan executor takes care of for executinga single procedure. The specification for the plannerengine is comprised of constructs presented by the gram-mar from Fig. 2. A state space of a finite state descriptionis represented by set of system variables ( )with significantly reduced domains. Physical signalsreadouts are introduced to the specification by means of

. Mapping between the model and hardwarereadouts is accomplished by definition of system vari-ables domains. Possible model state transformations areexpressed by means of atomic operations ( ).

.

2. The architecture

Fig. 1. Single installation of the automation software.

<qvariable>

<observable>

<procedure>

2.1. Planner Engine

IMPROVING DEPENDABILITY OF AUTOMATION

FOR FREE ELECTRON LASER FLASH

Bogusław Kosęda, Tomasz Szmuc, Wojciech Cichalewski


Special issue 33

1. Deutsches Elektronen-Synchrotron in Hamburg, member of theHelmholtz Association.

2. Distributed Object Oriented Control System.

Their specification consists of precondition, postcon-dition, reference to the executable code and estimate ofexecution time. Procedure is permissible only if its pre-condition evaluates to true. Postcondition becomes ful-filled after its successful execution. Execution time helpsin estimation whether the procedure is still in progress orhas presumably failed. Since every automated operationis performed on purpose, there is a way to specify pos-sible goals of automation. For these purpose there existsa construct . It specifies a valuation of subsetof system variables, which must hold for the operationmode to be active. Specification can be augmented withdefinitions of formal properties of the model (

). The only usage scenario of the planner engine isto configure target mode and let the software bring thesubsystem there. This process executes in cycles. Everycycle the state estimator guesses the status of superviseddevice, planner finds the sequence of atomic proceduresdriving the system into target operation mode and planexecutor performs first procedure from the plan. Afterreaching the target operation mode, planner enginerestricts itself to monitoring. In the case of single pro-

<opmode>

<formal-prop>

<specification> ::= { <definition> ";"}<definition> ::= <repexceptions> | <exception> | <observable> | <procedure> | <qvariable> | <opmode> |

<formalprop><observable> ::= <obsname> of type <obstype>

<doocsaddr><obstype> ::=<condition> ::= <relation> <junction> <relation><junction> ::= | " "<relation> ::= <obsname> <operator> <number> | <obsname> <bitop> integer <operator> integer<operator> ::=<bitop> ::=<number> ::= integer | float<procname>, <obsname>, <qname>, <qval>, <opname>, <pname>, <doocsaddr>, <description>,<message> ::= string<qvariable> ::= <qname> <qdomain><q domain> ::= <qvalue> {" ," <qdomain>}<qvalue> ::= <qval> <condition><opmode> ::= <opname> <state><state> ::= <state> {<junction> <state> }<state> ::= <qrelation><qrelation> ::= <qname> <qval> | <q name> <qval><procedure> ::= <proc name> <description> <doocsaddr>

<condtype> <condition> <condition> integer<condtype> ::= |<formalprop> ::= <pname> <ptype> <state><ptype> ::=<repexceptions> ::= <exctype> <doocsaddr><exctype> ::=<exception> ::= <interrupt> | <fault> | <warning><interrupt> ::= <description> <condition> <message>

<proc name><fault> ::= <description> <condition> <message><warning> ::= <description> <condition> <message>

def

observabletaken frombool | int | float | string

& |

== | != | < | > | <= | >=bitor | bitand | bitxor

qvariable

value ifopmode active when

== !=procedure description: trigger:allowed postcondition: cost:unless: when:specificationalways | never | possiblereport tofault | warning | interrupt

interrupt holds if report messageexecute procedurefault holds if report messagewarning holds if report message

Fig. 2. Grammar defining syntax of the specification language for both the planner and the exception handler.

cedure failure several scenarios depending on plan exe-cutor setup may happen. At present there are two setupspossible. First repeats failed procedure while the secondtries to find and execute alternative procedure.

Exception handler recognizes operation glitches andif possible executes appropriate remedy procedures. Ifexception cannot be dealt with automatically, it stopsthe automation software and warns the operators. In thecase of multiple exceptions it must choose the mostsuitable remedy procedure. Its specification language isdesigned for definition of exceptional situations. Theyare described by means of conditions defined in terms ofmonitored DOOCS properties. There are distinguishedthree categories of the exceptions. Permanent faults,temporary interrupts and warnings. Faults cause perma-nent break in machine operation. Interrupts are temporalglitches, which can be automatically dealt with. War-nings provide information about possibly approachingoperation problems.

2.2. Handler of Exceptional Events

3


Special issue34

VOLUME 3, N° 1 2009

3. Corresponding grammar may be found in Fig. 2.

the interfaces presented in the diagram. Figures 4 and5 present the design of the cooperation protocol in theform of Harel's statecharts [14] . Table 2 provides des-crip-tions of the states from the Fig. 4 and 5. Poorlydesigned cooperation protocol might cause automationsoftware to hang. Therefore it had to be verified for thedeadlock [13] and livelock [13] freedom. The SPIN [11]model checker was used for this purpose. Protocol designpre-sented in Fig. 3, 4 and 5 was modelled in the PRO-MELA language. Then the model has been checked forthe exis-tence of deadlocks and livelocks. It turned outthat all non-progressive cycles [11] found in the modeldid not cause starvation (livelock). They have been mar-ked as progressive by inserting a progress labels depictedas numbered bullets in 4 and 5. After inserting the labelsinto the model no invalid endstates [11] (deadlocks)have been found. Besides, the model has been verifiedto conform to its functional requirements presented inFig. 6.

4

5

3. Integrated formal verificationand testingIn this project, automated formal verification is reali-

zed by model checking [10]. The NuSMV [9] is a modelchecker used to verify formal properties included in thespecification for the planner. Dedicated converter trans-lates the model encoded in the specification language tothe equivalent model expressed in the NuSMVs input lan-guage. Definitions of formal properties, which need to befulfilled by the model, are expressed in the ComputationTree Logic (CTL) [10]. Fragmentary example of the NuSMVinput specification could be seen in Fig. 7. The model ofverified system is an asynchronous statemachine. Itsstate is described by symbolic variables defined in themodule and each transition is representedby corresponding module (e.g. ). Modu-le creates all the processes. Model consistsin sequential execution of nondeterministically chosenprocesses.

systems_stateswitch_to_manual

main execution

Above classification was introduced to facilitateconflict resolution in the case of multiple exceptionsoccurrence. If a fault occurs, automation software ispermanently suspended and appropriate message is sentto operators' console. Occurrence of an interrupt in caseof lack of faults entails execution of suitable remedialprocedure. Conflict resolution between interrupts isbased on calculation of subsumption relation. Morestrictly specified interrupts have precedence before moregeneral ones. The algorithm for deciding whether oneexception subsumes another utilizes two constraintsolvers. The [12] and the [12]. The ideaof calculating the relation is fairly simple. If one assumestwo exceptions and which conditions and .The algorithm reports the subsumption if there existthree valuations of variables (hardware readouts)in cnd1 and cnd2 meeting one of the followingstatements.

When above conflict resolution methods fail, theorder of appearance in the specification file decideswhich exception is handled first.

Both the runtime engines perform complementarytasks. Since they share the same hardware equipment,they must obey certain rules of cooperation. For thispurpose a protocol orchestrating their collaboration hasbeen designed. General diagram of the cooperationprotocol design is presented in Fig. 3. Table 1 explains

clp/bounds clpqr

E E cnd1 cnd2

V ,V ,V

E E iff

(cnd1(V ) cnd2(V ) (cnd1(V ) cnd2(V ))( cnd1(V ) cnd2(V ))

E E iff

(cnd1(V ) cnd2(V )) ( cnd1(V ) cnd2(V ))(cnd1(V ) cnd2(V ))

1 2

1 2 3

1 2

1 1 2 2

3 3

2 1

1 1 2 2

3 3

subsumes

subsumes

�¬

¬ ¬

¬

¬ ¬

� � �

�

� � � �

�

2.3. Cooperation Scenarios


Special issue 35

VOLUME 3, N° 1 2009

4. They should be interpreted according to the operational semantics described in the Stateflow User's Guide [8].5. A modeling language of the SPIN model checker.

Fig. 3. General scheme of communication between the planner and the exception handler.

To facilitate the process of automation design, dedi-cated software has been implemented. The toolbox allowssimulating continuous or step-by-step execution of theplanner engine. It provides the interface to display andsimulate the system state and integrates automaticformal verification. Some elements of the toolbox can beseen in the Fig. 7, 8, 9.

4. ConclusionUsefulness of the framework has been evaluated by

implementation of supervision software for RF-powerstation subsystem. This installation is responsible forsupplying cavities with energy necessary for particleacceleration. Unfortunately description of this complexinstallation is beyond of the scope of this paper. It can be


Special issue36

VOLUME 3, N° 1 2009

Description

State of supervised plant fits in the state space defined by the specificationA state of the target operation mode has been reachedA path to one of the target states has been foundTarget operation mode has been specifiedThe software is permitted to supervise the plantException handler reports an operation glitchException handler reports a permanent faultSuspend the plannerSuspend the exception handler

Stimulus name

STATE_RECOGNIZEDGOAL_REACHEDPLAN_SUCCGOAL_AIMEDAUTO_MODEGLITCHERRORFREEZE_PLANNERFREEZE_HNDLR

Table 1. Explanation of the data supplied to and exchanged between the parts of the protocol from Fig. 3.

Fig. 4. Design of the communication protocol for the planner.

Fig. 5. Design of the communication protocol for the exception handler.


Special issue 37

VOLUME 3, N° 1 2009

Table 2. Explanation of the state names from the Fig. 4 and 5.

Description

The planner is permitted to supervise the plantThe planner is suspendedA target operation mode has been specifiedNo target operation mode is specifiedThe planner executes single step of a planPlanning in progressPlanner performs state recognitionPlanner is incompletePlanning has failedState of the plant is unknownBoth engines are suspendedThe exception handler is suspendedThe automation engines are permitted to supervise the plantException detection in progressAll exceptions are being reported to the operatorException handling procedure in progress

Stimulus name

P_AUTOP_FROZENGOAL_IS_AIMEDGOAL_NOT_AIMEDSTEP_EXECUTIONPLANNINGSTATE_SCANNINGINCOMPLETEINC_PLANNINGINC_STATE_SCANNINGE_MANUALE_FROZENAUTOUPDATEREPORTING_EVENTPROCEDURE_EXECUTION

1. FREEZE_PLANNER FREEZE_PLANNER2. FREEZE_HNDLR FREEZE_HNDLR3. GLITCH P_FROZEN4. ERROR P_FROZEN5. MANUAL P_FROZEN6. GOAL_AIMED GOAL_NOT_AIMED E_FROZEN

� �

� �

� �

� �

� �

� � �

�

�

�

�

�

�

MODULEVAR

ASSIGN

MODULEASSIGN case

esac

MODULEASSIGN case

esac

MODULEVAR

processprocessprocess

FAIRNESS

SPEC EF

systems_state

FORCE_MANUAL_MODE: {FALSE,TRUE};MODULATOR_STATUS: {LOCKED_FOR_5_MIN,ERROR,OFF,ON};

next(FORCE_MANUAL_MODE) := FORCE_MANUAL_MODE;next(MODULATOR_STATUS) := MODULATOR_STATUS;

switch_to_manual(st)next(st.FORCE_MANUAL_MODE) :=st.FORCE_MANUAL_MODE = TRUE: FALSE;1: st.FORCE_MANUAL_MODE; ;

switch_to_auto(st)next(st.FORCE_MANUAL_MODE) :=st.FORCE_MANUAL_MODE = FALSE: TRUE;1 :st.FORCE_MANUAL_MODE; ;

main

state: systems_state;proc_switch_to_manual: switch_to_manual(state);proc_switch_to_auto: switch_to_auto(state);

running

-- reachability of MODULATOR_READY(state.FORCE_MANUAL_MODE = FALSE

& state.KLY_INTERLOCK_STATUS = ALL_GREEN& state.MOD_INTERLOCK_STATUS = ALL_GREEN& state.MODULATOR_STATUS = ON)

Fig. 6. Properties of the cooperation protocol, which prove its responsiveness and deadlock freedom.

Fig. 7. Fragmentary specification for the planner automatically translated to the NuSMV input language.


Special issue38

found in [1]. Despite the whole RF-power station is quitecomplex, it has simple operation scenarios. Six operationmodes have been specified. They are presented in Fig. 8.The system state was described by nine system variablesdepicted in Fig. 9. The exception handler was suppliedwith the specification of the following exceptions.

Personal interlock active (personal safety, perma-nent fault).RF-leakage detected (personal safety, permanentfault).Unrecoverable modulator fault (permanent fault).Modulator power supplier switch is off (human assis-tance needed).Only RF-inhibit activated (remote restart possible).General modulator problem (remote restart possible).IGCT stack overheated (hardware safety, wait till tem-perature drops).

The software has been used for several maintenancedays for driving the fifth RF-power station of the FLASH.It was used to drive the RF-power station to all specified

�

�

�

�

�

�

�

6

7

operation modes. It also managed to recover the RF-power station from several field quenches in the accele-rating structures ( ) and modula-tor faults ( ). These two are themost frequently occurring exceptions, which need to behandled automatically. Response to remaining specifiedfaults was verified by fault injection.

- TechnicalUniversity of Lodz, Department of Microelectronics andComputer Science, Al. Politechniki 11, 90-924 Łódź,Poland. E-mail: [email protected]

- AGH University of Science and Tech-nology, Department of Automatics, Al. Mickiewicza 30,30-059 Kraków, Poland.* Corresponding author

only RF-inhibit activatedgeneral modulator problem

AUTHORSBogusław Kosęda*, Wojciech Cichalewski

Tomasz Szmuc

References[1] Aghababyan A., Altarelli M., ,

, ISBN3-935702-17-5, 2006.

[2] Hensler O., Rehlich K., “DOOCS: a Distributed ObjectOriented Control System”. In:

, Protvino, 1996.[3] Ayvazyan V., Rehlich K., Simrock S., Sturm N., “Finite

et al. XFEL The EuropeanX-Ray Free-Electron Laser Technical Design Report

Proceedings of XV Work-shop on Charged Particle Accelerators

VOLUME 3, N° 1 2009

Fig. 9. The graphical user interface for observing and simulating the finite-state model of the planner for the RF powerstation.

Fig. 8. The interfaces for simulation and step-by-step execution of the automation software.

6. Personal interlock indicates potential threat to the personnelservicing the RF-power station. It also indicates presence of thepersonnel in the vicinity of high power microwave installations.

7. DRF-leakage is a hardware interlock signal reporting leakage of thehigh power electromagnetic field from the waveguide distributionsystem, which may cause serious injury of the person subjected tothe field.


Special issue 39

State Machine Implementation to Automate RF Opera-tion at the TESLA Test Facility”. In:

, Chicago, 2001.[4] Kosęda B., Cichalewski W., “Design and Implementation

of Finite State Machine for RF Power Station”. In:

, Kraków,Poland, 2005.

[5] Kosęda B., Cichalewski W., “Improvements of ExpertSystem for RF-Power Stations”. In:

, Gdynia, Poland, 2006.[6] Brandt A., Cichalewski W., Koseda B., Simrock S.,

“Automation of low level RF control operation for theVUV-FEL at DESY and future accelerators”. In:

, IV 5948, 2005.[7] Wagner F.,

, ISBN 0-8493-8086-3, 2006.[8] MathWorks, Inc.,

.[9] Cimatti A., Clarke E., , “NuSMV 2: An OpenSource

Tool for Symbolic Model Checking”. In:

, Copenhagen, Denmark 2002.[10] Huth M., Ryan M.,

, ISBN 0-521-54310-X,2004.

[11] Holzmann G.,, ISBN: 0-321-22862-6, 2004.

[12] Wielemaker J., . Avail-able at: http://gollem.science.uva.nl/SWI-Prolog/Manual/.

[13] . Available at:http://foldoc.org/.

[14] Harel D.,, vol. 8,

1987, pp. 231-274.[15] Storey N., , Addison

Wesley, ISBN 0-201-42787-7, 1996.

Proceedings of theParticle Accelerator Conference

Pro-ceedings of the 12 International Conference MixedDesign of Integrated Circuits and Systems

Proceedings of the13 International Conference Mixed Design of IntegratedCircuits and Systems

Proceedings of SPIE, Photonics Applications in Industryand Research

Modeling Software with Finite State Machines:A Practical Approach

Stateflow and Stateflow Coder User'sGuide

et al.Proceeding of

International Conference on Computer-Aided Verifica-tion

Logic in computer science, Modellingand Reasoning about Systems

SPIN Model Checker, The: Primer andReference Manual

SWI-Prolog 5.6 Reference Manual

Free On-Line Dictionary of Computing

Statecharts: A Visual Formalism for ComplexSystems Science of Computer Programming

Safety Critical Computer Systems

th

th

VOLUME 3, N° 1 2009

Abstract:

1. Introduction

2. Approaches of Urban Vehicle Traffic Control

Urban vehicle traffic control is one of the most com-plex problems due to the large number of variables orparameters involved and their unexpected variations.There are controlled inputs (by the traffic lights) anduncontrolled inputs (vehicles that enter on the currentlane from parking or from streets uncontrolled by trafficlights). The flow of the vehicle stream can be measuredby appropriate detectors (or sensors). Vehicle presencecan be detected and occupancy can be measured. Theunmeasured inputs and outputs (from/to parking places)introduce non deterministic factors. The flow splits (inintersections) can be measured or estimated but cannotbe controlled in an acceptable manner [8].

Better traffic control leads to improved safety for allroad users, shorter travelling times through thecontrolled part of the traffic system and it also reducesnegative environmental impact [11]. Therefore, vehicletraffic control systems have to face: variable inputs (partof them controllable) represented by the vehicle flowsentering the systems, variable transfer splits of the flowson the intersections and accidents that significantlymodify the parameters. These require the achieving ofadaptive control systems that take into account thevariable ratio of the rates with the aim to maintain a highthroughput and to reduce travelling time. The controlsystem gets information about traffic from the detectorsand controls it using the traffic lights.

The cycle of an intersection is a sequence of all (trafficlights) signals that are applied to open sequentially all thelanes that enter the crossroad. The cycle duration is thetime interval from application of a traffic light signal(starting of the cycle) of a phase until its next application.

A new approach for design and implementation of ur-ban vehicle control system is proposed. The vehicle streamson lanes are considered similar with the streams of ins-tructions in multitask programs. Real-time scheduling algo-rithms are used to allocate the green lights to phases.An adaptive component is used to calculate new vehicleflow parameters when a failure appears as a consequenceof an accident. The real-time schedulers use the parametersto obtain new feasible resource allocations.

Keywords: urban vehicle traffic control, real time schedu-ling, traffic congestion, real time control, dependability.

A phase is a part of the intersection cycle allocatedto any specific movement receiving the right-of-way or toany combination of traffic movements receiving the right-of-way simultaneously during one or more intervals.Usually, the intersection cycle duration is split intophases that open the input lanes such that the corres-ponding flows cross the intersection. The flow split refersto the ratio by which an input lane flow is divided intoseveral output flows.

Urban vehicle traffic control can be actuated or non-actuated. Control can be non-coordinated (implementedfor isolated intersections) or coordinated. The actuatedurban vehicle traffic control can be implemented usingthe following approaches: controlling the flows (i.e. thevolume control), density control, queue length control,singular event reaction, phase time extension until a mi-nimum gap out, and phase time extension until timeout.

The solution for vehicle traffic control problem con-tains: the intersection cycle durations (if such cycles arechosen), the durations of phases (the split of the cycle)and their periods if there are no cycles, the order ofphases (of each intersection) or their priorities, and theoffsets (between intersections or phases).

Papageorgiou present some methods for local,centralized or distributed control of vehicle urban traffic[14]. Bazan [3] presents a coordination method based onmulti-agent system that uses game theory to get thecrossing times and the synchronization of intersectionsignalling. The negotiation method can also be used [8].Intelligent vehicle traffic management can be used, too[6]. Non artificial intelligent coordination methods areoften based on optimization [15].

Kutil use a model of a simple traffic intersectionwhere the state variables represent the queue length andthe average waiting times in the queues to obtain a fairtraffic control [7]. They use the balancing waiting timesto obtain a linear quadratic regulator and a nonlinearmodel predictive controller.

Liu and Tate propose an intelligent adaptation speedsystem that uses in-vehicle electronic devices to enablethe speed of vehicle to be regulated automatically [12].This offers a flexible method for speed management andcontrol in urban area. Avella present a method tosolve the shortest path problem under resource cons-traints for vehicle fleet on a road net [1].

The majority of approaches (using deterministic orheuristic methods) consider the vehicle traffic system asworking under probable (often previously measured andstatistically expressed) conditions. But as a matter offact, the demand (required green light) times and thegranted durations (of neighbour intersections green

et al.

et al.

et al.

USING PRE-EMPTION

FOR DEPENDABLE URBAN VEHICLE TRAFFIC

Tiberiu Letia, Sergiu Barbu and Florin Dinga


Special issue40

lights) can vary considerably from instance to instanceand are not known completely at the moment of the deci-sion making. Even when these are known, the proposedmethods are based on the estimated time demands of thetraffic and on the probable values (splits) of the rates.

3. Pre-emption Based Controlof Urban Vehicle TrafficUnlike the previous ones, another approach is based

on the worst case behaviour of the system. That meansthe usage in design of the highest accepted demands andthe highest requirements relative to the timelines insteadof the corresponding probable values.

The usage of real-time scheduling methods to signalcontrol of the traffic lights in urban vehicle traffic isintroduced in [9]. Vehicle flows on the lanes associated toan intersection phase are considered similar with thestream of instructions (of a task) that has to be processedby a processor. Each vehicle stream has its own period(that can be different from the periods of other phases ofthe same intersection) and duration to cross the inter-section. The proposed method is a feedback control. Itsimplementation fulfils real-time constraints. The resultedvehicle flows are expected to fulfil timing constraints too.

Figure 1 represents the vehicle streams of the trafficsystem.

Lu present a feedback control real-time sche-duling framework for adaptive real-time systems [13].They use feedback control theory to design algorithms

Fig. 1. Example of urban vehicle traffic net.

et al.

that satisfy the transient and steady state performance ofreal-time systems.

One of the main problems of urban vehicle trafficcontrol has to solve the scheduling of resources repre-senting the places used by vehicles on lanes or inter-sections (most critical resources). The scheduling algo-rithms can be categorized as static or dynamic. In staticscheduling algorithms have complete knowledge aboutstream set and its constraints (such as deadlines, crossingtimes, precedence constraints and future demand times).In dynamic scheduling the algorithms have no completeknowledge about stream set or its timing constraints.dynamic scheduling algorithms can be divided into algo-rithms that work in sufficient resource environment andthose that work in insufficient resource environment. Thetraffic congestion is an example when the system reachesa state in which, at least for the moment, the availableresources are insufficient.

Figure 2 shows the temporal relations between thedemanded moments of time (dt) and green light dura-tions of two consecutive intersections i-1 and i. Each ofthem should be opened within a specified period (T). Theoffset (O) between them also has to be implemented. Thejitter (J) appears due to variation of vehicle speed oropening of the (linked) phase from the previous inter-section. The opening of a phase before the demand mo-ments of time (dt) is useless. If the end of the crossingtime (C) is after the deadline (dd) this can lead to conges-tion. When a phase is opened at the dt (just when thevehicle stream arrives), because the vehicles have the de-sired speed (they are moving), the throughput is higher.This leads to a higher usage of the intersection (repre-senting a critical resource). If the demanded durationsare higher than the granted durations for some periods oftime, this leads to congestions, also because lane capa-cities are exceeded.

Figure 3 describes the UML (Unified Modelling Langu-age) state machine of a phase from an intersection. Theswitching of the phases is performed by the implemen-tation of the real-time scheduler by updater (Figure 4)and dispatcher (Figure 5). They can implement differenttypes of real-time schedulers used to control the urbanvehicle traffic systems. The updater calculates the waitingtimes (w) and adds the phases (using add (phase) me-thod) to the ready queue when they expire. It also calcu-lates the number of requests (req) of each phase that arenot honoured.


Fig. 2. Temporal relations between phases of two consecutive intersections.

Special issue 41

Fidge describes the most largely used real-timescheduling methods and their tests [4]. A review of real-time scheduling methods is given in [16]. Between themare: RMS (rate monotonic scheduling), EDF (earliestdeadline first) and SPS (static priority scheduling). Usingsuch scheduling methods for the network of intersectionscomposing urban vehicle traffic system, a system thatfulfils some specified timing constrains is obtained.

An output lane is fed by one or more input lanes. Ifthere are more input lanes, one of them (usually the onewith the highest vehicle rate) is chosen as main inputlane. The opening moment of the main input lane of thecurrent intersection should be correlated with theopening moment of the output lane (transformed in aninput lane in the next intersection). When the vehicleplatoons released (periodically) from the main input laneof the current intersection arrive at the waiting queue ofthe next intersection, it is desired to find the corres-ponding phase already open such that a isobtained. If this requirement cannot be fulfilled, the cor-responding phase of the next intersection should beopened not later than the deadline. This deadline is calcu-

green wave

The real-time schedulers use the following parameters:- the crossing time (C) of a vehicle stream during

a cycle (period) through an intersection,- the period of a phase (T),- the offset of the phase (O),- the phase local priority and- the global priority (when a distributed scheduling

policy is implemented).

In Figure 5 are denoted by:- cp the current phase,- fp the first phase of the ready queue (readyQ),- update() the recalculation of the ready queue

according to the scheduling algorithm,- remove(x) the removing of the phase x from the

ready queue,- red(x), yellow(x) and green(x) the application of

the corresponding colour to the phase x.

For jitter implementation the diagram from theFigure 5 has to be extended with a new state andtransitions to catch the demand events.


Fig. 4. UML state machine of Updater.

Fig. 3. UML state machine of an intersection phase.

Fig. 5. Time driven dispatcher UML state machine.

Special issue42

lated such that the number of vehicles that entered on thelane that links these two intersections does not overflow(at any time) its capacity.

The real-time scheduling algorithm chooses betweenavailable (ready) phases the one which has to be currentlyopened according to the intersection policy using thephase (lane or flow) parameters.

Taking into account the article of Avizienis [2],the dependability of an urban vehicle traffic system isgiven by the following attributes: availability (readinessfor usage - i. e. the acceptance of vehicle entrance in thetraffic), reliability (continuity of service - the moving ofvehicles without unnecessary unbounded stops), safety(absence of catastrophic consequence on the user),confidentiality (absence of unauthorized disclosure ofinformation, usually less important for vehicle traffic sys-tem in regular usage), integrity (absence of impropersystem alteration) and maintainability (ability to undergorepairs and evolutions). The failures of urban vehicle traf-fic system are:- failures of the control system caused by bad control

decisions, message transmissions or signalling ofevents or states;

- failures of traffic systems (distributed controlledprocess) caused by exceeding of specified demands ordriver's faults that lead to accidents.

The vehicles that remain inside an intersection aftertheir phase loses the right of crossing (green lights),because they cannot enter the output lanes, involvecongestions [10]. Their number multiplied by a coeffi-cient dependent on the structure of the intersection canbe used as a measure of the current degree of congestion.The average values of the congestion degrees of all inter-sections of the traffic system provide information aboutcurrent congestion degree of the entire system. The evo-lution of the average congestion degree can be used toevaluate the traffic system behaviour under the imple-

4. Dependable Urban Vehicle Traffic Systemet al.

mented control algorithms.A fault of a driver can lead to a traffic failure (an

accident) that blocks the vehicle streams of a street.Following this the remained vehicle streams are modified(some of them split) such that the traffic flows avoid theblocked lanes. As a consequence, new parameters shouldbe provided to traffic lights controller (based on schedu-ling algorithms) to adapt to the modified environmentand having the goal to avoid the congestion of the sys-tem. The congestion of an intersection can lead to thecongestion of the entire traffic system if it is highlyloaded with vehicles.

The on-line control uses the estimation of flows basedon the measure of flow inputs and the flow splits. Usingthe real-time scheduling algorithms, the control systemestimates if the necessary crossing times lead to a feasiblesolution (that fulfils the timing constraints). The localcontrollers receive the parameters (offset, period, greenduration and priority) of each phase and implement theon-line schedulers that send the signals to the trafficlights.

The centralized adaptive algorithm activated at thedetection of a failure is:

for

forfor

while

end

all intersectionsEstimate or receive from local controllers the splitsof the rates.

all intersectionsall phasesCalculate the necessary crossing time.

(feasibility if schedulling is not fulfilled)Reduce the crossing time of each phase proportio-nally with its global priority, but not lower thana specified limit.

Communicate to local controllers the new schedulingparameters.


Fig. 6. Traffic simulator window.

Special issue 43

5. Testing and evaluationThe performance evaluation of urban vehicle traffic

system can be developed from the concepts of real-timesystems given by [5]. The evaluation can be based on:qualitative binary criteria, qualitative gradual criteria andquantitative criteria.1. Qualitative binary criteria are: timelines (the ability

to meet some specified deadlines), no unboundeddelay nor arbitrarily long crossing (or travelling)times, functional correctness, permanent readiness,all applicable physical constraints and congestionprevented.

2. Qualitative gradual criteria are: safety, reliability,availability, congestion, simplicity, and fault tole-rance, graceful degradation on the occurring ofundesired events, portability (of the control system),flexibility (to change of the vehicle traffic structure)and extensibility (of the control system with thedevelopment of the traffic net).

3. Quantitative criteria are: worst case travelling timeson a specified path, worst case crossing times of anintersection, worst case duration to detect the failuresand to correct the consequences (speed of adapta-tion), capacity (throughput) reserves and transfercapacities (throughput) of road net system or inter-sections.

To evaluate the proposed control method a specialurban vehicle traffic simulator was built as can be seen inFigure 6. It uses the microscopic method for simulation ofvehicles on lanes and a macroscopic method to evaluatethe number of vehicles inside intersections. The simulatoris able the calculate the congestion degree of eachintersection taking into account the number of vehiclesthat remain inside the intersection after the traffic lightsof the lanes they leave change to the red light, and theintersection structure. The values of the current numberof vehicles (inside intersection) and the intersectioncongestion degree are displayed on the intersectionrectangle. The current number of vehicles contained intothe entire system is printed on the upper side of thewindow. The simulator has buttons to modify the inputflows of the traffic system and to choose differentschedulling algorithms.

The average intersection congestion degrees are usedto evaluate the entire vehicle traffic system congestiondegree. This degree as well as the total number of vehiclesthat remain inside the traffic system after the transitoryregime can be used to evaluate the control performancesof the different control algorithms.

Figure 7 presents the variations of the total numbersof vehicles (steady state) with the input flows, using thealgorithms EGT (classical extended green time), RMS andEDF respectively. The lowest value of the number ofvehicles characterises a traffic system with higher vehiclethroughput.

Figure 8 shows the steady state relationships relatingthe input flows' changes to system congestion degreeusing the same algorithms. The lowest congestion degreecorresponds to the best control algorithm.

Relative to the considered (practical measured) regu-lar values of the traffic rates (corresponding to around

50% of vehicle generator frequency), the input flows wereincreased and decreased by the vehicles generator of thesimulator. Each time, the number of vehicles that remaininside the simulated traffic system after the transitoryregime is stored and so is the system congestion degree.They are represented in Figure 7 and Figure 8. Similargraphics were analysed for the system dependability.

Figure 7 shows that EDF algorithm leads to a lowernumber of vehicles moving into the system, so the trafficsystem throughput is higher. Figure 8 shows that RMS andEDF algorithms have lower congestion degrees (close toeach other) compared to classical EGT algorithm. Whenthe traffic rates have low values the differences betweenthese three algorithms are not significantly different fromthe point of view of throughput and congestion. The real-time schedulling algorithms (EDF and RMS) work better inthe range of 50-80%. The system congestion degree islower at the upper input flow values due to the fact thatthe vehicles that exceed the system throughput capacityare stopped to enter into the traffic controlled area.

The urban vehicle traffic dependability can be impro-ved by specification, design of the control system andsynthesis of the control algorithms. Observations of the

Fig. 7. Variations of steady total vehicle numbers with inputflows.

Fig. 8. Variations of the system congestion degrees withinput flows.

6. Conclusions


Special issue44


urban vehicle traffic behaviour when failures appear areuseful to obtain better specification of description andrequirements.

Models that describe more closely the behaviour ofdrivers when failures appear should be used to improvethe requirements of the control system. The proposedmethod uses different periods for the phases of the sameintersection. Usually, the periods of phases linked ina path should be correlated. Further studies should bedeveloped to find the need (the effect) of modification ofphase periods at the failure appearance.

The local priorities are used to schedule or analyse thefeasibility of critical resources scheduling. The globalpriorities are used to determine the global behaviour ofthe traffic system. They serve to maintain the mainfeatures of the system when failures appear. The relationsbetween global priorities and quantitative criteria (fortraffic performance evaluation) are to be studied with theaim to improve dependability.

The performance evaluation results (from simulations)demonstrate that the proposed algorithms provide bettertransient and steady state performance when trafficvolumes are at low values when traffic failures appeared.At high volumes, the controlled traffic system has betterperformances with real-time scheduling algorithm, butwithout a throughput reserve the control system is notable to correct completely the effect of failures. Thenecessary reserve is depends on the place of the expectedfailure and the current volumes of neighbour flows.

-Technical University of Cluj-Napoca, Departament. ofAutomation, 15 C. Daicoviciu St., 400020 Cluj-Napoca,Romania, tel: +40-264-438282, fax: +40-264-592055.E-mails: [email protected],

[email protected],[email protected].

* Corresponding author

AUTHORSTiberiu Letia*, Sergiu Barbu and Florin Dinga

References[1] Avella P., Boccia M., Sforza A., “Resource constrained

shortest path problems in path planning for fleet mana-gement”, ,vol. 3, 2004, pp. 1- 17.

[2] Avizienis A., Laprie J. C., Randel B., Landwehr C., “Basicconcepts and taxonomy of dependable and secure com-puting“,

, vol. 1, 2004, pp. 11-33.[3] Bazzan A. L.C., “A distributed approach for coordina-

tion of traffic signal agents”,, vol. 10, 2005, pp. 131-164.

[4] Fidge C.J., “Real-time schedulability tests for preem-ptive multitasking”, , vol. 14, 1998,pp. 61-93.

[5] Halang W., Gumzej R., Colnaric M., Druzovec M.,“Measuring the performance of real-time systems”,

, vol. 18,2000, pp. 59-68.

[6] Kirschfink H., Hernandez J., Boero M., “Intelligent traf-

Journal of Mathematical Modelling Algorithms

IEEE Trans. on Dependable and Secure Compu-ting

Autonomous and Multi-Agent Systems

Real-Time Systems

TheInternational Journal of Time-Critical Systems

E-mails:E-mails:

fic management models”, , 2000, pp. 36-44.[7] Kutil M., Hanzalek Z. and Cervin A., “Balancing the

waiting times in a simple traffic intersection model”.In:

, 2006 (to appear).[8] Letia T., Astilean A., Hulea M., Valean H., “Flow price

based vehicle traffic distributed control”. In:

, 2004, pages 91-96.[9] Letia T., “Real-time approaches of urban vehicle traf-

fic”. In:, 2006, pp. 346-350.

[10] Letia, T.: “Avoidance of urban vehicle traffic conges-tions”.

, Elsevier Publishing, vol. 11, part 1,2006, pp. 183-189.

[11] Lindley J. A., “Urban freeway congestion: Quantifi-cation of the problem and effectiveness of potential so-lutions”, ,vol. 57, 1989, no. 1, pp. 27-32.

[12] Liu R., Tate J.:, “Network effects of intelligent speedadaptation systems”, , vol. 31, 2004,pp. 297-325.

[13] Lu C., Stankovic J. A., Son S. H., “Feedback control real-time scheduling: framework, modelling and algo-rithms”, , vol. 23, 2002, pp. 85-126.

[14] Papageorgiou M., Diakaki C., Dinopolou V., Kotsialos A.,Wang Y., “Review of road traffic control strategies”,

, vol. 91, 2003, no. 12, pp.2043-2067.

[15] Porche I., Lafortune S., “Dynamic traffic control: decen-tralized and coordinated methods”,

, vol. 9-12, 1997,pp. 930-935.

[16] Sha L., Abdelzaher T., Arzen K.-E., Cervin A., Baker T.,Burns A., Buttazzo G., Caccamo M., Lehoczki J.,Mok A. K., “Real Time Scheduling Theory: A Historicalpers-pective”, , vol. 28, 2004,pp. 101-155.

Proc. of ESIT

Proc. of 11 IFAC Symposium on Control in Trans-portation Systems

Proc. ofthe 2 International Workshop on Discrete-Event SystemDesign

IEEE-TTTC International Conference on Automa-tion, Quality and Testing, Robotics

Proc. of 11 IFAC Symposium on Control in Trans-portation Systems

Institute of Transportation Engineers Journal

Transportation

Real-Time Systems

Proceedings of the IEEE

IEEE Conference onIntelligent Transportation Systems

Real-Time Systems

th

nd

th

VOLUME 3, N° 1 2009

Special issue 45

Abstract:

1. IntroductionFault prevention, fault tolerance, fault removal, and

fault forecasting are the four main means to attain thevarious attributes of dependability [4]. Fault preventionand fault tolerance aim to prevent introducing faults, orto avoid service failures when faults occur. Fault removaland fault forecasting, instead, mean to reduce numberand severity of faults, and to estimate present and futureincidences and consequences of faults. Among them,fault tolerance is the most promising mechanism to meetthe dependability requirements. Fault-tolerant systemswork under the assumption that they contain faults (e.g.,made by humans while developing or using systems, orcaused by aging hardware), and aim to provide specifiedservices in spite of faults being present. Fault tolerancedepends on redundancy, fault detection, and recovery.Many fault-tolerant systems are complex because ofredundancy, re-configurability, and various interactionsbetween their components. This complexity has a strongimpact on system architecture, as fault occurrenceshave to be taken into account from the earliest designstages on of systems required to be dependable. There-fore, architecture design is a crucial aspect for fault-tolerant systems, as indicated by well-known safety me-chanisms such as masking, dynamic redundancy, anddesign diversity (e.g., N-version programming, recoveryblocks) [8].

A component-based software architecture is presentedto support the process of designing and developing fault-tolerant computerised control systems. To this end, wecombine an idealised fault-tolerant component, the C2architecture style and protective wrappers, and embedfault tolerance techniques into component definitions. Theresulting architecture is described by normal- and abnor-mal-activity components aiming to support a wide range offault tolerance features. Use of this architecture enables toreason about system dependability already from the earli-est development stages on, and to customise fault tole-rance strategies according to application characteristics.

Keywords: software engineering, software architecture,fault tolerance, and component technique.

Component-Based Software Engineering (CBSE) focu-ses on producing software systems by composing prefa-bricated components, which can improve the produc-tivity and quality of target systems. In recent years, theemphasis of research on and practice in CBSE has chan-ged from functional aspects to non-functional ones.

Particularly, dependability of component-based systemsis considered as one of the most crucial non-functionalproperties in CBSE. To cope with complexity and faulttolerance requirements, it may be beneficial to combinein their development process well-established faulttolerance techniques with component techniques, as wellas to employ the Unified Modeling Language (UML) [10]to describe component-based software architecturemodels providing fault tolerance.

In a component-based system, the software architec-ture specification captures system structure by identi-fying architectural components and connectors, and re-quired system behaviour by specifying how componentsand connectors are intended to interact. It is desirablethat all components show only their normal behaviours.However, certain abnormal behaviours exist when someunexpected conditions occur. In CBSE, the abnormal be-haviours of components are usually represented by a setof exceptions defined by the component developers.It is impossible to eliminate all abnormal behaviours,but one can reduce them, and handle them properlyafter their occurrences. The main goal of this paper is todesign a comprehensive architecture to develop fault-tolerant systems from components. By embedding faulttolerance mechanisms into an integration architecture,normal and exceptional behaviours of system compo-nents are specified.

The body of this paper is organised as follows. Section2 briefly introduces an idealised fault-tolerant compo-nent meeting the architecture style C2 as defined in [7].Section 3 describes the integration of idealised fault-tolerant components and the C2 architecture. Section 4presents the main activities of designing fault-tolerantsystems out of components.

2. An idealised fault-tolerant componentand C2 architecture styleAn idealised fault-tolerant component [5] is a struc-

turing concept for coherent provision of fault tolerancein a system as shown in Fig. 1 (a). It includes both normaland abnormal responses in the interface between inter-acting components. Idealised fault-tolerant componentscommunicate through request or response messages,only. On receiving a service request, an idealised compo-nent will react with a normal response if the request issuccessfully processed, and with an external exception,otherwise. Such an external exception may be due to aninvalid service request, in which case it is called interfaceexception, or due to a failure in processing a validrequest, in which case it is called failure exception.Internal exceptions are associated with errors detected

INCORPORATING FAULT TOLERANCE INTO COMPONENT-BASED

ARCHITECTURES FOR EMBEDDED SYSTEMS

Shourong Lu, Wolfgang A. Halang


Special issue46

within a component that may be corrected, allowing theoperation to be completed successfully; otherwise, theyare propagated as external exceptions.

C2 is a software architecture style for systems withintensive user interfacing. The style is component-based,and supports large-grain re-use and flexible system com-position, emphasising weak bindings between compo-nents [7]. A C2 architecture as shown in Fig.1 (b) consistsof software components and connectors, which transmitmessages between components. Components maintainstate, perform operations, and exchange messages withother components via two interfaces (named top andbottom). Each interface consists of a set of messages thatmay be sent or received. Inter-component messages areclassified into two types, viz. requests to a component toperform an operation, and notifications that a givencomponent has performed an operation or changed state.In the C2 architectural style, both components andconnectors have a top and a bottom interface. Systemsare composed in a layered style, where a component's topinterface may be connected to the bottom interface ofa connector, and its bottom interface may be connectedto the top interface of another connector. Each side ofa connector may be connected to any number of compo-nents or connectors.

3. Integration of idealised componentsinto C2Guerra [3] introduced the concept of the

“idealised C2 Component” (iC2C), depicted in Fig.2, as anequivalent, in structure and behaviour, to the idealisedfault-tolerant component. The latter's purpose is to struc-ture the architectures of component-based software sys-

et al.

tems compliant with the C2 architectural style. Servicerequests and normal responses of an idealised fault-tole-rant component are mapped as requests and notificationsin the C2 architectural style. Interfaces and failure excep-tions of an idealised fault-tolerant component are consi-dered subtypes of notifications. An iC2C is composed offive elements: NormalActivity and AbnormalActivity com-ponents, and iC2C top, iC2C internal, and iC2C bottomconnectors.

The NormalActivity component processes service re-quests and answers them through notifications. It imple-ments the normal behaviour, responsible for error detec-tion during normal operation, and the signalling ofinterface and internal exceptions. The AbnormalActivitycomponent is responsible for the exception handlers(error recovery) of the iC2C, and the signalling of failureexceptions. While an iC2C is in its normal state, theAbnormalActivity component remains inactive. When anexceptional condition is detected, it is activated tohandle the exception. In case the exception is success-fully handled, the iC2C returns to its normal state and theNormalActivity component resumes processing.Otherwise, a failure exception is signalled to componentsin lower layers of the architecture, which become respon-sible for handling it.

The iC2C top connector encapsulates the interactionbetween the iC2C and components located in upper levelsof an architecture. It is responsible to guarantee thatservice requests sent by the Normal-Activity and Abnor-malActivity components to other components located inupper levels of the architecture are processed synchrono-usly, and that response notifications reach the intendeddestinations. The iC2C top connector also performs do-


Fig. 1. Idealised fault-tolerant component and C2 architecture style.

Special issue 47

nent wrapping is a well-known structuring technique,and a cost-effective solution to many problems in compo-nent-based software development [2].

In our extension, a set of detectors is wrapped as iC2Cconnectors connecting the normal activity component,which is viewed as redundant software, and responsiblefor (1) detecting exceptional conditions anticipated bythe specification and signalling them by raising excep-tions in the provided interface of the exception compo-nent, and (2) signalling other exceptional conditionsspecific to the implementation of the component, byraising exceptions. This set consists of well-defined errordetectors concerned with special purposes such as “Fail-Stop Processor”, “Acknowledgment”, “I Am Alive”, “AreYou Alive” [6]. When a constraint violation is detected,the detector sends an exception notification to the Ab-normalActivity component. In addition to error detectorsembedded in the NormalActivity component, an excep-tion component is required to specify the raising of localand co-operating exceptions, i.e., signalling of an appro-priate exception. Hence, an exception component is de-signed working as an extra information holder, andkeeping information about application exceptions, whichare used by the other components. In other words, theexception component interacts with the handler, concur-rency and strategy component located in the Abnor-malActivity component in order to obtain and updateinformation about exception occurrences and handling.The exception component should have the required inter-face for getting information and the one for updatinginformation. The former allows the application and othercomponents to obtain information about exceptionoccurrences, whereas the latter allows its clients to up-date information about exceptions.

main translation, converting incoming notifications toa format the iC2C understands, and out-going requests toa format the application understands. The iC2C internalconnector is responsible for message routing inside theiC2C. The destination of a message sent by the internalelements of the iC2C depends on its type, and whether theiC2C is in a normal or abnormal state. The iC2C’s bottomconnector connects it with the lower components of a C2configuration, and serialises the requests received. Oncea request is accepted, this connector queues new requestsreceived until completion of the first one. When a requestis completed, a notification is returned, which may bea normal response, an interface exception, or a failureexception.

The proposed architecture is constructed by addingfault tolerance mechanisms to normal- and abnormal-activity components as shown in Fig.3. The fault tole-rance mechanisms are responsible for detecting errors orsuspicious activities, and for executing appropriate reco-veries whenever possible. The incorporation of faulttolerance mechanisms into the iC2C architecture requiresre-defining normal and abnormal activities.

In the iC2C architecture, the NormalActivity compo-nent encapsulates a desired functionality (normal activi-ty). It may represent both a single component and a con-figuration established through connectors. To embed er-ror detection mechanisms into the NormalActivity com-ponent, the concept of protective wrappers, known to bethe most general approach to develop fault-tolerant sys-tems based on COTS components, is employed. Compo-

4. Extending the iC2C architecture by faulttolerance mechanisms

4.1. Definition of the NormalActivitycomponent


Fig. 2. An idealised C2 component.

Special issue48

Raising an exception results in an interruption ofa component's normal activity, followed by a search foran appropriate exception handler to deal with theexception signalled. Therefore, the AbnormalActivitycomponent can be defined as an exception handlingmechanism as shown in Fig.3 aiming for error recovery.When an exception is raised, the exception handlingmechanism begins to work. It should be able to find andactivate an exception handler to recover from errors, andto put the system back into a coherent state.

Abnormal behaviour is not restricted to failures ofa single component, but also associated with invalidinteractions between two or more components, and withcombinations of component failures. An intra-compo-nent exception is raised by an individual component. Thestrategy to deal with it is based on local exception hand-lers, which are associated to a component's implemen-tation. Their main responsibility is to cope with antici-pated exceptions, which are more related to the compo-nent's application domain, and are declared in its requi-

4.2. Definition of the AbnormalActivitycomponent

red interfaces, i.e., they are responsible to handle theexternal exceptions of the component's required inter-faces and the internal exceptions raised by the compo-nent's implementation. When possible, the handlersshould implement forward error recovery to mask theexceptions.

Inter-component exceptions are raised by componentconfigurations. The strategy to deal with them has toconsider the integration of pre-existing components intoa new configuration, and is based on co-operating excep-tion handlers. These are associated with hierarchicalstructure, and deal with exceptions that could not behandled within the single components. The handlers areresponsible for providing error recovery and masking bymeans of redundant components in the configuration,and resolving failure semantics mismatches betweenserver components and their clients. They should becapable of dealing with all exceptions signalled by a ser-ver component. Upon receiving an exception from a ser-ver component, the handlers should try to mask it in-voking the same operation on a redundant (replicated ordiversely designed [1]) server component, in case it is


Fig. 3. Extending the iC2C architecture by fault tolerance mechanisms.

Special issue 49

available. The handlers are also responsible for trans-lating unmasked exceptions from the server component'sdomain to the client component's domain, before propa-gating them to client components. Exceptions requiringno further adaptation are automatically propagated.When direct propagation is not possible, a new exceptionis created wrapping the unmasked exceptions raised bythe server component.

As there are intra- and inter-component exceptions,the architecture is designed to consist (see Fig. 3) ofHandlerComponent (HC), ExceptionHandlingStrategy-Component (EHSC), and ConcurrentExceptionHandling-Component (CEHC).

The is res-ponsible to locate the different handlers required to re-solve an exception. It implements services related to thestrategy for exception handling. Hence, its responsibi-lities are deviation of control flow and search for hand-lers. It plays a central role in the architecture, and inter-acts with all other components. From Exception-Compo-nent it receives information about an exception occurren-ce while searching for its corresponding handler. Its pro-vided interface provides the service for handler search.

The handling and propagation of an exception de-pends on whether it is an intra-component exception oran inter-component one. For the former, the handling islimited within the component's AbnormalActivity. If theexception cannot be handled, then it is propagated.A handler may also explicitly re-signal the exception toa component in a layer of the architecture. An inter-com-ponent exception raised on receiving a service request bya component is not handled there, since it does notindicate that the component is faulty. Therefore, theexception is propagated to the client component, whichissued the request. The client component handles theexception in the same manner as an intra-componentone, because it possibly indicates a fault within theclient component. The strategy to search for handlers ofintra- and inter-component exceptions can be describedusing a pseudo-code as follows:if exception is propagated from intra-component then

if local handler exists thencall local handler;

if not handled thengo to a higher (action) level handling;

end if;else

go to a higher (action) level handling;end if;

elseerror detection in client component;if exception is raised (error has been found) then

if local handler exists thencall local handler;if not handled then

go to a higher (action) level handling;end if;

else go to a higher (action) level handling;end if;

default handlerend if;

end if

ExceptionHandlingStrategyComponent

The is constructed with a set ofhandlers to cope with abnormal activities, i.e. it is res-ponsible for fault masking and recovering. After a handleris found, EHSC asks the HandlerComponent to invoke theexception handler. According to the hierarchical struc-ture, handlers may be associated with a component,a connector, or a configuration, as well as with excep-tions themselves (default handlers). A default handler isexecuted when there is not a more specific handler in anapplication. The HandlerComponent has a required inter-face, which allows the EHSC to invoke a handler when theappropriate handler has been found. If an exceptionreaches the lowest level of an architecture, the handlerfor the entire system should be executed.

The isdesigned for concurrent co-operative actions, which usethe services provided by the exception handling strategyin order to carry out the strategy for concurrent excep-tion handling. When co-operating exceptions are raisedduring an action, the exception resolution is accom-plished by this component. It has a provided interface,which is accessible by applications to create concurrentco-operative actions.

To design co-operative component activities usingnested atomic actions, it is described how each indivi-dual component is involved in such activities, and co-operative exception handling for all participants in eachaction is developed. We employ the Coordinated Atomic(CA) action scheme [9], in which components take part,by defining a group as an action, and participants arecomponents. Then, only co-ordinated recovery needs tobe activated within the participant tasks of a group. Thisobviously restricts system design, but enables to regardeach group as a recovery region, and to attach faulttolerance activities to each group participant.

Each group has participants, which may be activatedby some external activities, e.g., tasks, and which co-operate within the group's scope. Participants executeobject methods that should have been designed to workco-operatively by means of shared objects. Participantsmay enter asynchronously into a group activity, butshould exit in a synchronised way. Each group participanthas a set of exception handlers that are designed torecover the group co-operatively from eventual errors.If any suitable handler has not been defined at least inone of the group participants, an “abort exception” israised and, then, the group activity must be undone(backward error recovery), and such an exception must besignalled to the enclosing group. If the backward errorrecovery is not executed successfully within the group,a “failure exception” is signalled to the enclosing group.

Exceptions can be raised by participants during anaction. Some of them can be handled internally by a localhandler attached to the participant that raised anexception. If an exception occurrence is not handledinternally by a participant, then all action participantsshould handle it co-operatively. A set of co-operatingexceptions is associated with each action. Each partici-pant has a set of handlers for (all or part of) these excep-tions. Participants are synchronised and probably diffe-rent handlers for the same exception had to be invoked inthe different participants. These handlers are executed

HandlerComponent

ConcurrentExceptionHandlingComponent


Special issue50


concurrently, and co-operate in handling the exceptionin a co-ordinated way. Therefore, we employ local hand-ling at the level of individual components. If localhandling does not succeed, an exception is propagated tothe level of an action in which this component is involvedto be handled co-operatively. When action-level hand-ling is not possible, an exception is propagated to thecontaining action.

The newly defined AbnormalActivity component en-capsulates the exception handling mechanisms (intra-component and inter-component exception handling).After implementation, it requires an interface, whichshould have the function . If an excep-tion is successfully handled, returnsa message, which is sent to the NormalActivity compo-nent. Then, processing is resumed. Otherwise, an excep-tion is raised in the body of .

With the concept of the extended iC2C we aim to addfault tolerance mechanisms to the NormalActivity andAbnormalActivity components of an iC2C. In our appro-ach, error detector and exception components are encap-sulated into the NormalActivity component, with errordetectors contained by a wrapper. These detectors areresponsible to verify that messages do not violate theacceptable behaviour constraints specified for a system.The exception handling mechanism is embedded into theAbnormalActivity component.

The advantage of integrating fault tolerance techni-ques into the process of designing and developing com-puter control systems required to be dependable is thatappropriate fault tolerance techniques can be selectedfrom a set of mechanisms provided and customisedaccording to application characteristics. This approachwill enhance the safety of control systems. Employing itsbuilt-in extension mechanisms, UML can be extended tosuit dependable applications with respect to aspects suchas error detection, error recovery, or configuration ofredundancy measures. Thus, for each aspect to be model-led, the most expressive techniques can be selected bythe user. Furthermore, UML and the here specified exten-sions constitute an effective environment to design de-pendable computer control systems in a comprehensiveway taking fault tolerance into account throughout theentire development process.

- Fernuniversitätin Hagen, Chair of Computer Engineering, 58084 Hagen,Germany. E-mails: [email protected],[email protected].* Corresponding author

handleException()handleException()

handleException()

5. Conclusion

AUTHORSShourong Lu* and Wolfgang A. Halang

References[1] Anderson T., Lee P.A., “Fault Tolerance: Principles and

Practice”. In:, vol. 3, Springer-Verlag, 1990.

[2] Anderson T., Randell B., Romanovsky A., “Wrapping theFuture”. In: ,

Dependable Computing and Fault TolerantSystems

Proc. 18 IFIP World Computer Congressth

2004, pp. 165 - 173.[3] Guerra P.A. de C., Rubira C.M.F., de Lemos, R., “An

Idealized Fault-Tolerant Architectural Component”.In: , LNCS, Springer-Verlag, 2003, pp. 21 - 41.

[4] Laprie J.-C., “Dependability: Basic Concepts and Termi-nology”. In:

, IEEE Computer Society Press, 1995, pp.42 - 54.

[5] Lee A., and Anderson T.,. Springer-Verlag, 1990.

[6] Saridakis T., “A System of Patterns for Fault Tolerance”.In: .

[7] Taylor R.N., Medvidovic N., Anderson K.M., WhiteheadE.J., Robbins J.E., Nies K.A., Oreizy P.D., and DubrowL.A., “Component - and message-based architecturalstyle for GUI software”,

, vol. 22, issue 6, 1996, pp. 390 - 406.[8] Torres-Pomales W., ,

NASA/TM-2000-210616, 2000.[9] Xu J., Randell B., Romanovsky A.B., Rubira C.M.F.,

Stroud R.J., and Wu Z., “Fault tolerance in concurrentobject-oriented software through coordinated errorrecovery”. In: ,1995, pp. 499 - 508.

[10] . OMGdocument ptc/2003-08-02, 2003.

Architecting Dependable Systems

Proc. 25 IEEE Intl. Symp. on Fault-TolerantComputing

Fault Tolerance: Principles andPractice

Proc. EuroPLoP

IEEE Trans. on SoftwareEngineering

Software Fault Tolerance: A tutorial

Proc. Symp. on Fault-Tolerant Computing

Unified Modeling Language: Superstructure

th

VOLUME 3, N° 1 2009

Special issue 51

Abstract:

1. IntroductionFaults (transient, permanent or intermittent) appear-

ing during system operation may result in logical errors,which can be critical for the realised applications [1,11].Transient faults are especially critical as they dominate incontemporary technologies. Hence, an important practi-cal issue is to evaluate dependability of software applica-tions in the presence of faults. It is particularly critical inmany reactive systems (e.g. nuclear plants, satellites,aircrafts, chemical industry, medicine). One kind of suchapplications, erroneous behaviour of which might havesome serious consequences, are control algorithms. Thispaper studies dependability of software implementationsof explicit versions of DMC (Dynamic Matrix Control) andGPC (Generalised Predictive Control) Model PredictiveControl (MPC) algorithms. The investigation is based onsoftware implemented fault injection, which has beenadapted to reactive applications [1,6]. In particular,a new approach to test result qualification is proposed.

MPC is recognised as the only advanced control tech-nique, which has been very successful in practical appli-cations [14,15,16,17,21]. As MPC algorithms use modelsof processes for calculation of the control policy they canbe successfully applied to processes, which are difficultto control. In particular, processes with significant timedelay for which the PID controller does not give satis-factory control performance. Among different MPC tech-niques, DMC [4] and GPC algorithms [3] are the mostpopular. Both algorithms use linear models. The DMCalgorithm uses a non-parametric model consisting ofstep-response coefficients of the process. Such a modelcan be easily obtained in industry, but to precisely des-cribe a process many coefficients are needed. The GPCalgorithm uses a parametric model in the form of a dis-crete difference equation. Usually, such models are signi-ficantly less complicated in terms of the number of para-

This paper studies dependability of software implemen-tation of DMC (Dynamic Matrix Control) and GPC (Gene-ralised Predictive Control) Model Predictive Control (MPC)algorithms. Explicit formulation of algorithms is consideredin which the control laws are calculated off-line. Depen-dability is evaluated using software implemented faultinjection approach. Tests are performed in the control sys-tem of a remotely controlled robot vehicle used in nuclearplants.

Keywords: dependability, fault injection, process control,and predictive control.

meters than the step-response ones.The paper is structured as follows. First, in Section 2,

the case study is presented. The investigated controlalgorithms and their explicit formulations are shortlycharacterised in Section 3. Next, Section 4 presents thefault injection test bed, experiment set-up and some newaspects of adapting experiments to control algorithmsspecificity. Finally, Section 5 discusses experimentalresults and the paper is concluded in Section 6

The case study process for this research is a remotelycontrolled robot vehicle for nuclear plants [5] shown inFig. 1. The vehicle must act reliably in a hazardous andunsafe environment. Application of such vehicles cansignificantly reduce radiation exposure to personnel andimprove maintenance programme performance. Discrete-time model of the process is (the sampling time is0.5 min)

where , , ,are parameters. Input of the controlled

process relates to the voltage applied to the vehicle'sengine. The vehicle model limits the voltage range to[-5;5]. Output y of the process is the velocity of thevehicle. Values of at each sampling instant are consi-dered to be the result of the whole application and aresubject to correctness analysis.

The considered process has significant time delay. Forsuch processes the classical PID controller usually doesnot give satisfactory control. That is why MPC algorithmsare used.

.

(1)

In the MPC algorithms [14,15,16,17,21] at each con-secutive sampling instant a set of future control incre-ments

(2)

2. Remotely controlled vehicle

y k b u k– b

u

y

( )= ( 9)

0.022276 0.019823 -1.6836380.704688

9 – u k– –a y k– –a y k–

b b aa

10 1 2

9 10 1

2

( 10) ( 1) ( 2)

= = ==

k

Fig. 1. Remotely controlled robot for nuclear plants.

3. Model predictive control

FAULT SENSITIVITY OF EXPLICIT DMCAND GPC ALGORITHMS

Piotr Gawkowski, Maciej Ławryńczuk, Piotr Marusak, Janusz Sosnowski, Piotr Tatjewski


Special issue52

is calculated assuming that for ,where is the control horizon. It is usually done in sucha way that the future control error values (i.e. differencesbetween the reference trajectory and the predicted valuesof the output) are minimised over the prediction horizon

. The following quadratic cost function is typically used

(3)

where ,

are vectors of length , isa weighting matrix, is the reference (i.e. the set-point) and are predicted values of the outputover the prediction horizon, for . Thesepredictions are calculated using a dynamic model of theprocess. Typically, , which decreases the dimen-sionality of the optimisation problem and leads to smallercomputational load. Because only the first element of thedetermined sequence (2) is applied to the process, thecontrol law is

(4)

At the next sampling instants the prediction is shiftedand the whole procedure is repeated.

When a linear dynamic model of the process is used, itis possible to express the output prediction as the sum ofa forced trajectory (which depends only on the futureinput moves and a free trajectory (whichdepends only on the past)

(5)

where isa vector of length . The dynamic matrix of dimensiona-lity is composed of step response coefficients ofthe model.

Thanks to using a linear model and the superpositionprinciple (5), the cost function (3) becomes a quadraticone. Hence, the vector of optimal control input incre-ments is

(6)

where is a matrix of dimensionalitywhich is calculated off-line.

In the DMC algorithm the process dynamics is descri-bed, in a convenient way, by a discrete-time, finite step-response model. Thus, for any sampling instant , outputof the model is

(7)

where are step-response coefficients, is the horizonof the process dynamics.

The DMC control law (3) can be expressed in thefollowing form [14,21]

p NN

N

N

p N

N <N

k k

NN N

N N

k

s D

�

�

�

�

u

u

u

u

u

j

=1,...,

( )) ( )u y0

3.1. Dynamic Matrix Control algorithm

(8)

where and , are coefficients cal-culated off-line. The total number of parameters is . Theobtained explicit control law is a linear feedback from thedifference between the set-point trajectory and values ofthe manipulated variable increments calculated at pre-vious sampling instants. The structure of the explicit DMCalgorithm is shown in Fig. 2.

The GPC algorithm uses a process model in the form ofa discrete difference equation describing the processinput-output relation

(9)

where , are coefficients and , define order of thedynamics.

The GPC control law can be expressed in the followingform [21]

(10)

where and , arecoefficients calculated off-line. The total number ofparameters is . The obtained explicit GPC con-trol law is a linear feedback from the reference trajectory,values of the manipulated variable calculated at previoussampling instants and values of the controlled variablemeasured at previous sampling instants. Structure of theexplicit GPC algorithm is shown in Fig. 3. Comparing thestructures of both studied algorithms, it is evident that inthe DMC algorithm, there is only one feedback from theprocess output variable and feedback from values ofpast process input increments. In the GPC algorithm,there are feedbacks from the current process output valueand last past values of the output increments and fromlast past values of the process input increments.

The step-response usually contains a large number ofelements. At the same time, the process can be describedprecisely enough by a discrete difference equation ofa relatively low order. Hence, a model used in the GPCalgorithm has significantly less parameters than the mo-del used in the DMC algorithm (i.e. , ).It should be stressed, however, that a non-parametric

D

a b n n

n n

D

nn

D>>n D>>n

Fig. 2. Structure of the explicit DMC algorithm.

3.2. Generalized Predictive Control algorithm

i i A B

A B

A

B

A B

+ +2

1�


Special issue 53

also shows that such disturbances give the most inte-resting results for the fault susceptibility analysis [11].Deeper discussion upon the fault injection policy can befound in [9,11,18].

The input of the whole application is therequired vehicle's velocity, a step from 0 to 1 at isconsidered during the tests. The DMC algorithm uses thestep-response model obtained from the model (1) (thehorizon of the process dynamics ) whereas theGPC algorithm uses directly the model (1). In bothalgorithms , and .

The whole experiment is conducted by FITS automa-tically. At the end of the experiment synthetic (aggre-gated) results for each fault location are given. An im-portant issue (frequently neglected in the literature) isqualification of experimental results. In case of a typicalcalculation-oriented application correctness of its resultis usually easy. It is much more complicated for otherclasses of applications, especially related to real-timesystems [18]. Control algorithms require complex analysisof the controlled process behaviour. Values of y at eachsampling instant are considered to be the result of thewhole application and are subject to correctness analysis.In general, 4 classes of test results are distinguished:

C: correct vehicle behaviour (ISE 20),INC: incorrect (unacceptable) vehicle behaviour(ISE 20),S: test terminated by the system due toun-handled exception,T: timed-out test.

where the standard factor ISE (Integrated Sum of SquaredErrors) is proposed as a measure of result ( ) correctness.The reference ISE value (obtained during GR) is 12.79(due to delayed vehicle response). System exceptions (S)are generated by hardware mechanisms embedded incontemporary COTS (commercial off-the-shelf) systems,e.g. memory access violation.

Analysis of fault effects requires detail informationupon the faults injected and the application behaviour.FITS can provide details about every test (simulated faultinjection) that allow manual replay the whole testexecution. Moreover, all the events and user messagesoccurring during the test are recorded. The tested appli-cation is instrumented to save its outputs (here simula-tion results, i.e. a set of control signals in subsequentsampling instants) into separate files for each test (filenames managed by FITS). This gives a possibility fordeeper analysis (post-experiment) of fault effects in thecorrelation with the injected fault and observed beha-viour for each single test.

The cost of the DMC algorithm implementation is 173bytes of binary code (50 machine instructions). At thesame time, the GPC algorithm implementation takes 212bytes (59 instructions). The main difference is the numberof executed instructions, i.e. a single simulation execu-tion of the DMC and GPC algorithms takes 121261 and12192 machine instructions, respectively. Such a resultis not surprising as the control law used in the DMC

( ( ))=10

=100

=20 =5 =1

y kk

D

N N

y

ref

u p

�

�

�

�

�

�

5. Experimental results

step-response model is obtained on the basis of a simpleexperiment but it is necessary to conduct a full identifica-tion experiment to obtain a parametric model.

In order to examine the fault sensitivity of the explicitimplementation of the analysed control algorithms theconsidered controllers are implemented as applicationswritten in language. These applications execute a pre-defined reference trajectory on the process (vehi-cle), whose simulator is also the part of the application.The applications (one for the DMC and the second one forGPC) are then examined with the use of a fault injectiontest bed. It's concept is based on the software emulationof a fault during the run-time of the application undertest. In this research FITS fault injector is used [10,19].It uses standard Win32 Debugging API to control theexecution of the software application under test. In thewhole process the following steps can be distinguished:optional source code instrumentation of the tested appli-cation, golden run execution, experiment configuration,fault injection and results analysis.

In order to assure good experiment controllability,are introduced [6]. FITS disturbs directly the

application only within those areas. Here, the parts of thetested applications disturbed during the experiments(dashed box) as well as process models (not disturbed) aremarked in Fig. 2 and Fig. 3. To simplify tracing faulteffects the captured and collected by theFITS during experiments are inserted [19]. This mecha-nism provides supplementary communication betweenthe tested application and the FITS. As a result, the testedapplication signals some measures related to internalvariables values, output signal deviations etc.

During the (GR - reference execution with-out faults) the execution trace and reference results arelogged. Additionally, statistic information is collected onthe tested application (e.g. resource usage, code size,instruction distribution). Those measures help to inter-pret experimental results and to profile experiments to bedone (e.g. by elimination of injecting faults into unusedresources). FITS simulates faults by disturbing the run-ning application. In this process an important issue ispolicy of selection the type, location and time of faultinjection (fault triggering). In this study single bit-flipfaults within CPU and FPU registers, applications' dataand machine instruction code are considered. Faults areinjected pseudorandomly in time (program execution)and space (bit position within disturbed resource, distri-bution over applications' memory). There is a commonconsensus in the literature that such fault model wellmimics Single Event Upset (SEU) effects. The experience

Fig. 3. Structure of the explicit GPC algorithm.

testing areas

user-messages

Golden Run

4. Fault injector and experiment set-up

Cy k( ( ))ref


Special issue54

5 10 15 20 25 30 35 40 45 50 55 60

-10

-5

0

5

10

um ax

umin

5 10 15 20 25 30 35 40 45 50 55 60

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0 10 20 30 40 50 60-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

1.2

1.4

yref

algorithm has 100 parameters whereas the GPC controllaw has only 14 parameters.

Fig. 4 depicts summarised results of experimentalevaluation of DMC and GPC algorithms (results categoriesC, INC, S and T are described in Section 4) from experi-ments with faults located in CPU registers, static code,instruction stream, FPU and used data area. The maindifference can be seen in the case of faults located in thedata area used by the considered algorithms. As the DMCalgorithm uses much more parameters (100) than the GPCone (14), it is more insensitive to single disturbances.It is worth noting, that both algorithms can be furtherhardened by introducing exception handling. In the expe-riments carried out, no exception handling is present.Hence, approximately 50% of faults affecting the staticimage of the code, executed instruction stream and CPUregisters resulted in unhandled exceptions (most of themrelate to memory access violations). Previous experienceshows [9,11,12,13,18,19] that such behaviour can beefficiently improved.

A great number of tests have been performed (morethen 25000 per algorithm) and their results compared.Because of limited space only two time-plots are presen-ted here. Fig. 5 compares simulation results of the golden

run (solid lines) and two example incorrect vehicle beha-viour (dashed lines). In the first case (left figures), faultinjected into static code of the DMC algorithm imple-mentation results in slow response and big control errors(ISE=31.44). It leads to unacceptable output response(slow and with big control errors). Moreover, the manipu-lated variable ( ) oscillations appear (the left plot).In the second case (right figures) the responses froma different experiment with the DMC algorithm are shown(fault also injected into the static code). This time viola-tion of the manipulated variable constraint is observed(as shown in the left graph). It would result in anoscillatory movement of the robot forward and backrepeatedly.

Fig. 6 shows the distribution of ISE values observed(faults located in the static code) for tests considered asunacceptable (INC). It is worth noting that both the DMCand GPC algorithms have similar distribution for low ISEvalues (<100). Moreover, more than 66% of the INC testshave very high ISE values ( 100), which means that thecontrol system is unstable. Obviously, other correctnessmeasures should be also considered and need furtherdevelopment and investigation.

u

�


Fig. 4. Summary of the experimental results.

Fig. 5. DMC algorithm simulation results: left: slow response and big control errors (ISE=31.44); right: manipulatedvariable u constraint violation (ISE=23.94); solid line - golden run, dotted line - incorrect vehicle behaviour.

5 10 15 20 25 30 35 40 45 50 55 60-0.2

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

yref

Special issue 55

Fig. 6. Distribution of ISE in incorrect category.

6. ConclusionsThe paper presents a novel approach to evaluation and

comparison of dependability of software implementationof two most popular MPC algorithms, i.e. DMC and GPC. Forthis purpose software implemented fault injector is used.Explicit formulation of these algorithms is considered inwhich the control laws are calculated off-line. The experi-ments show that the performance of both algorithms isdifferent in the case of some faults (in data), as well astheir faults susceptibility. It is worth noting that robust-ness of software implementation can be improved bysome basic software fault detection/tolerance techni-ques. The new measures of process behaviour are alsoconsidered to be developed. Those topics will be coveredin the future research.

- Institute ofComputer Science, Faculty of Electronics and Infor-mation Technology, Warsaw University of Technology,ul. Nowowiejska 15/19, 00-665 Warszawa, Poland.Tel. +48 22 234 77 11, fax. +48 22 825 16 35. E-mails:{P.Gawkowski, J.Sosnowski}@ii.pw.edu.pl

- Institute of Control and Computation Engineering,Faculty of Electronics and Information Technology,Warsaw University of Technology, ul. Nowowiejska 15/19,00-665 Warszawa, Poland. Tel. +48 22 234 76 73, fax.+48 22 825 37 19. E-mails: {M.Lawrynczuk, P.Marusak,P.Tatjewski}@ia.pw.edu.pl.* Corresponding author

AUTHORSPiotr Gawkowski* and Janusz Sosnowski

Maciej Ławryńczuk, Piotr Marusak and Piotr Tatjewski

References[1] Benso A., Prinetto P., F

. KluwerAcademic Publishers, 2003.

[2] Blevins T. L., Mcmillan G. K., Wojsznis M. W.,, ISA, 2003.

[3] Clarke D. W., Mohtadi C., Tuffs P. S., “Generalized pre-dictive control - I. The basic algorithm”, ,vol. 23, 1987, no. 2, pp. 137-148.

[4] Cutler R., Ramaker B., “Dynamic matrix control - a com-puter control algorithm”, ,Houston, USA, 1979.

[5] Dorf C. D., , Addison-Wesley,Reading, 1995.

[6] Gawkowski P., Sosnowski J., „Experiences with softwareimplemented fault injection”. In:

, Zurich,

ault injection techniques andtools for embedded systems reliability evaluation

Advancedcontrol unleashed

Automatica

AIChE National Meeting

Modern control systems

International Confe-rence on Architecture of Computing Systems

Switzeralnd, VDE Verlag GMBH, 2007, pp. 73-80.[7] Gawkowski P., Sosnowski J., “Software implemented

fault detection and fault tolerance mechanisms - part I:Concepts and algorithms”,

, vol. 51, 2005, no. 2, pp. 291-303.[8] Gawkowski P., Sosnowski J., “Software implemented

fault detection and fault tolerance mechanisms - partII: Experimental evaluation of error coverage”,

, vol. 51, 2005, no. 3,pp. 495-508.

[9] Gawkowski P., Sosnowski J., Radko B., “Analyzing theeffectiveness of fault hardening procedures”. In:

,2005, Saint Raphael, France, pp. 14-19.

[10] Gawkowski P., Sosnowski J., “Analysing system suscep-tibility to faults with simulation tools”,

, vol. 4, 2006, pp. 123-134.[11] Gawkowski P., Sosnowski J., “Dependability evaluation

with fault injection experiments”,, vol. E86-D, 2003, no. 12, pp.

2642-2649.[12] Gawkowski P., Sosnowski J., Experimental validation of

fault detection and fault tolerance mechanisms. In:

. Cannes, France, pp. 181-186 , 2002.[13] Gawkowski P., Sosnowski J., “Analyzing fault effects in

fault insertion experiments“, The On-Line Testing Work-shop, IEEE Computer Society Press, 2001, GiardiniNaxos - Taormina, Italy, pp. 21-24.

[14] Maciejowski J. M., ,Prentice Hall, Harlow, 2002.

[15] Morari M., Lee J., “Model predictive control: past, pre-sent and future”, ,vol. 23, 1999, no. 4/5, pp. 667-682.

[16] Qin S. J., Badgwell T., “A survey of industrial modelpredictive control technology”,

, vol. 11, 2003, no. 7, pp. 733-764.[17] Rossiter J. A., , CRC Press,

Boca Raton, 2003.[18] Sosnowski J., Gawkowski P., Lesiak A., “Fault injection

stress strategies in dependability analysis”,, vol. 33, 2005, no 2. , pp. 679-699.

[19] Sosnowski J., Lesiak A., Gawkowski P., Włodawiec P.,„Software implemented fault inserters”. In:

, 2003,Ostrava, Czech Republic, pp. 293-298.

[20] Sosnowski J., Gawkowski P., Lesiak A., “Fault injectionstress strategies”, In:

, Brazil, 2003, pp. 258-263.[21] Tatjewski P.,

, Springer, London, 2007.

Kwartalnik Elektroniki i Tele-komunikacji

Kwar-talnik Elektroniki i Telekomunikacji

The 11 IEEE International On-Line Testing Symposium

Annales UMCSInformatica AI

IEICE Transactions onInformation and System

The7 IEEE International Workshop on High Level DesignValidation and Test

Predictive control with constraints

Computers and Chemical Engineering

Control EngineeringPractice

Model-based predictive control

Control andCybernetics

IFAC Work-shop on Programmable Devices and Systems

The 4 IEEE Latin - American TestWorkshop 2003

Advanced control of industrial processes,structures and algorithms

th

th

th


0%

10%

20%

30%

40%

50%

<30 <40 <50 <60 <70 <80 <90 <100 <200 <500 <1000 >=1000

GPC

DMC

Special issue56

Abstract:

1. IntroductionComputer-based digital controllers typically have the

ability to monitor a number of discrete and analog in-puts, execute complex control algorithms, and driveseveral outputs, all at defined, often very high, speeds.In general, computer-based digital controllers must de-tect external events and respond to them by takingappropriate actions. It is required that all above ope-rations and calculations take place within the requiredtime. This imposes timing requirements on hardware andsoftware of the computer-based control systems. Moreprecisely, computer-based digital controllers must havesufficient processing power, sufficient high-speed input/output hardware peripherals and operating system, fulfil-ling more or less hard timing requirements and handlingerror conditions in a predefined way.

Limited processing power combined with a non-opti-mised hardware and software components introducedelays and non-deterministic behaviour of the real-timesystem. Digital control theory normally assumes evenlyspaced sampling intervals and a negligible (or constant)control delay between sampling and actuation [1]. How-ever, this can seldom be practically achieved in a real, re-source-constrained system. Time delays and timing varia-tions in control loop execution degrade the control per-formance and may, in extreme cases, lead to instability.

Control theory does not very often advise how todesign controllers to take that limitation into account[2]. Usually, control algorithms are designed withoutconsideration of their real-time implementation details.Designers usually try to separate the real-time aspectsand the dynamics of the control system. They develop

Traditionally, control algorithms are designed withouta consideration of their real-time implementation details.The performance of a digital control system, besides thesampling period, depends on many variables, such as thecontrol loop execution time, jitter, complexity of the con-trol algorithm etc. In this paper attention is focused on theinteraction of the parameters of the scheduled tasks and onthe performance of control loops closed with digital con-troller. A design approach that is based on the relativespeed classification of the control system has been propo-sed. The approach is illustrated by the analysis of controlsystems developed for laboratory magnetic levitationprocess.

Keywords: digital control, real-time control, time-criticalsystems, FPGA, magnetic levitation, timing model.

controllers that guarantee all tasks deadlines underworst-case load and external interrupt occurrence sce-nario. The design of safety-critical controllers is based onthis approach. Plant can be suitably controlled, but at thecost of poor computer resource utilization. However, ifsampling rate bound determined by the speed of the con-trol computer is close to the minimal required by theplant, then the sampling rate of the control system beco-mes time critical. For such a system the performance ofthe real-time operating system is essential for correctoperation of the control system.

It has been stated in previous work (see for example[10], [12]), that integrated approaches combining twodisciplines real-time computation and control theory,results in better quality for digital control systems. This isalso true for networked or multirate systems [4], [6], [9].This problem is analysed in this paper. The notion of rela-tive speed of the control system is introduced and illu-strated, on the example of magnetic levitation (MagLev)real-time control. Control system design approach basedon the relative speed system classification is proposed.

The general scheme of a digital control system isgiven in Fig. 1 [11], [3]. The operation of the closed-loopsystem can be split into three main tasks: sampling, con-trol algorithm computation and actuation. Models andmethods used by discrete-time control theory implicitlyimpose the timing of the tasks in the computer imple-mentation.

The tasks are associated with the events, includingtimer event, termination of a data frame transmission,signals that data are ready to be read from the inputdevices, fault detection, etc. The tasks usually share thesame processor and exchange data with each other.

Although a great variety of scheduling methods isavailable, in this work periodic task scheduling method isassumed.

The following timing assumptions are made in rela-tion to the three main tasks of a digital control loopoperation:1. Sampling is performed at equidistant time instants

given by , but some variation of are allowed.2. The actuation is performed instantly when the control

signal is delivered to the D/A converter.3. The control algorithm computation is executed as

soon as the input data are available.4. The control algorithm design is based on correctly

identified models of the process and the disturbances(referred to "nominal models").

2. Relative speed of a digital-controlledplant

T T0 0

u(kT )0

SPEED ANALYSIS OF A DIGITAL CONTROLLER

IN TIME CRITICAL APPLICATIONS

Paweł Piątek, Wojciech Grega


Special issue 57

Fig. 1. The general scheme of a computer controlled sys-tem. A/D - analog to digital converter, D/A - digital toanalog converter, Rv - reference value, C - controller.

5. For the nominal models, it is possible to estimatemaximal, admissible sampling period that wouldguarantee acceptable control performance. Thissampling period can be estimated as:

(1)

where:- is time period for "ideal" control system, where

modelling and identification errors as well as time delaysand variations of time period are negligible and con-trol parameters are optimal. For "ideal" control systemsampling period can be extended to the upper limit defi-ned e.g. by the Shannon theory.

6. The performance of the closed-loop control system isa strictly monotonic function of . Any applied sam-pling period improves control performance.For the improvement is not observed.

T

T

0

0

- is the sampling period guaranteeing robust opera-tion of the control system, if it is under the influence ofexternal and internal disturbances. This sampling/con-trol period, besides fulfilling the Shannon theorem, canbe selected following one of various "rules of thumb" [1],[3], depending on the desired closed-loop system perfor-mance.

7. The proposed control platform (processor, peripheralshardware and operating systems) are characterized byminimal (a shortest accessible) closed -loopexecution time, estimated as:

"simple"

(2)

where:- is the control loop execution time for simple control

algorithms,- is the control loop execution time for complex

control algorithms.

The control algorithm is classified as a "simple", if thepseudocode of the controller task includes no more than5-10 operations (loops are excluded). The examples of

algorithms are: incremental PID or state feed-back controller.

If the pseudocode of the controller includes morethan 10 operations or loops then the algorithm is classi-fied as "complex". The examples of "complex" control al-gorithms are: time-optimal, model-reference controller,predictive controller.

Fig. 2 illustrates typical timing models one can use forregularly sampled process.

For the model a), sampling and actuation are perfor-med at the same sampling time (time delay is zero). Forthis model we have: and so calledis fulfilled.

Model b) from Fig. 2 is more realistic because it takesinto account that control task takes time. Control loopexecution time is constant and is less than samplingperiod: . Causality rule is not fulfilled in this case.The causality rule can be fulfilled if actuation is perfor-med at the next sampling instant, e.g. one step delay isassumed. It is so called [5].

causality rule

Strictly Proper Control Law


Special issue58

VOLUME 3, N° 1 2009

Fig. 2. Timing models that can be used for regularly sampled process.

A laboratory magnetic levitation system presented onFig. 4 was used as an example of relatively high-speedplant [7], [8]. The MagLev was chosen with regard to itsspecific nonlinearities and fast dynamics.

The identified parameters of MagLev process were:, . The parameters of the MagLev

digital control system and its relation to the proposedrelative-speed definitions are given in Table 1.

This plant, when controlled by a PC or a general-purpose microcontroller, can be classified as a relativelymedium-speed system. MagLev controlled by a simple 8-bit microcontroller is classified as relatively high-speedsystem. It is a representative example to show that:

usage of more efficient control system with shortercontrol period results in better quality of controlby changing classification of system from relativelymedium-speed to relatively low-speed,usage of more efficient control system with shortercontrol loop execution time results in better qualityof control by better satisfying the causality rule.

Experiments with MagLev plant controlled by twodifferent control systems were carried out. The first confi-guration was based on PC computer and the second wasbased on FPGA circuits. Both of them were developedusing an extension board consisting of the FPGA circuit.Control algorithm for PC-based control system was calcu-lated as a controller task by MATLAB/Simulink real-timeapplication. In this case the FPGA circuit was used only forsignal generation for analog/digital and digital/analogconverters and for providing data to the PC computer.In the case of FPGA-based system the control algorithmwas calculated directly by the FPGA circuit. The PC wasused only for monitoring the plant and logging the data.

Fig. 3. Moving time critical control system (A) to the me-dium speed class (adapting the parameters) and to lowspeed class (B), by changing the control platform.

Table 1. Control system parameters for MagLev.

�

�

T0

Model c) also takes into account that control tasktakes time, but time delay is variable and is less thansampling period: . The causality rulecan be fulfilled if the actuation is performed at the nextsampling instant, i.e. one step delay is assumed.

The constant delay can be compensated during thealgorithm design. For continuous-time design, Smithpredictor can be implemented for discrete-time design,plant model augment method can be applied [3].

For model d), the observed time delays are longerthan the sampling period. The control task is to complexfor assumed sampling period. Both causality rule andreal-time constraints are not fulfilled in this case. Theplant cannot be controlled in a proper way.

The relative speed of control system can be charac-

terized by the factor .

The following classification of control system isproposed:1. The control system will be referred to

if (model from Fig. 2a).

2. The control system will be referred to

if

from Fig. 2c).

3. The control system will be referred to

if (model from Fig. 2d).

Note that high-speed execution platform applied forthe process described by a slow dynamic is classified asrelatively low-speed control system. A digital controlsystem will be considered as if it is classi-fied as relatively high-speed or relatively medium-speed.A low-speed control loop applied for fast dynamic processwill be classified as relatively high-speed control system.

relatively low-

speed

relatively

medium-speed

relatively high-

speed

time-critical

(models from Fig. 2b and

For the control loop is relatively high-speed

and therefore becomes time-critical. It can be classifiedas medium- speed system, if (Fig. 3):a) after assuming the condition is ful-

filled. Non-robust control is available in this case,b) after assuming the condition is ful-

filled. Applications of "simple" control algorithms be-come possible.Such adaptation of control system parameters is limi-

ted and in most cases cannot move the system to low-speed class. This class can be reached by changing thecontrol platform: using the most efficient processor, bet-ter operating system, etc. (case B in Fig. 3).

3. Adapting control system parameters fortime-critical system

4. Example: real-time control of MagLevsystem


Special issue 59

VOLUME 3, N° 1 2009

PCPC FPGAmicrocontroller

n.a. n.a.

A comparison of the process response (FPGA-basedcontrol system), for different control periods 700 μ and40 μ , is presented in Fig. 6. Smaller values of the over-shoot and the shorter settling time are observed in thecase of MagLev controlled by FPGA-based control systemwith the shorter control period

a)

b)

a)

b)

ss

Fig. 6. A comparison of the MagLev process response con-trolled by the system based on FPGA (700 μs control period)and the system based on FPGA circuits (40 μs controlperiod): a) complete range of desired ball movement, b)magnification of up-motion part.

Fig. 7. A comparison of the MagLev process response con-trolled by the system based on PC (700 μs control period)and the system based on FPGA circuits (40 μs controlperiod): a) complete range of desired ball movement, b)magnification of up-motion part.

T0

Both control systems are presented in the Fig. 4.

The ferromagnetic ball has followed the changingreference signal. The square wave with 2s period wasapplied as the reference value. The desired centre of theball movement was in the distance of 0.0125m from theelectromagnet and the amplitude of movement was equalto 0.002m. Exactly the same parameters were used forboth of the tested control systems.

Digital version of PID algorithm was used for both per-formed experiments. The parameters of the algorithmwere recalculated for the specific hardware architecturei.e. the type of arithmetic or the applied control period.The results of the experiments are presented in Fig. 5, Fig.6 and Fig. 7.

A comparison of the PC controlled process responsewith the response of control system based on FPGA circuitis presented in Fig. 5. The control period of 700 μs wasused for both control systems. The evident improvementof control quality is observed in the case of MagLev con-trolled by FPGA-based controller that guarantees shortercontrol loop execution time .

a)

Fig. 4. Block diagram of control systems: a) PC-based, b)FPGA-based.

b)

Fig. 5. A comparison of the MagLev process response con-trolled by PC system (700 μs control period) and the systembased on FPGA circuits (700 μs control period): a) completerange of desired ball movement, b) magnification of up-motion part.


Special issue60

VOLUME 3, N° 1 2009

A comparison of the process response controlled by PCcomputer and the control system based on FPGA circuits ispresented in Fig. 7. Smaller values of the overshoot andthe shorter settling time are observed in the case ofMagLev controlled by FPGA-based control system with theboundary control period and the boundary control loopexecution time .

Digital, computer based control systems are the appli-cations that pose the very sharp timing requirements,because digital control theory usually assumes a highlydeterministic sampling. Consequently, the application ofthe controller performing a number of real-time tasks inthe control loop makes the analysis and design morecomplex.

The performance of a digital control system dependson many variables, such as sampling period, control loopexecution time, jitter, and complexity of the control algo-rithm. The performance of a digital control system de-pends not only on the performance of its individual com-ponents but also on their interaction and cooperation.

The focus of this paper was the interaction of para-meters of the scheduled tasks and the performance ofcontrol loops closed over digital controller. In particular,we have proposed a new design approach that is based onthe relative speed system classification and applies thefollowing paradigm: the application platform should beselected in such a way that closed-loop execution timeand process dynamics are balanced. The relative speed ofthe system should be located just bellow the line sepa-rating "time critical" solution, giving optimal utilizationof computing system resources.

The results of presented experiments have showedthat both factors: reduction of the control period andreduction of the loop execution time improve quality ofcontrol for magnetic levitation system. Both solutionshave located the relative speed of the MagLev control sys-tem below the "time-critical" range. The obtained over-shoots and settling times were much better with FPGA-based controller. The maximal improvement of controlquality was observed for simultaneously reduced controlperiod and control loop execution time. This effect wasobtained for control loop closed directly PID controlapplication embedded into FPGA circuit.

- Department ofAutomatics AGH University of Science and TechnologyAl. Mickiewicza 30, 30-059 Kraków (Cracow), Poland.E-mails: [email protected], [email protected].* Corresponding author

5. Conclusions

via

ACKNOWLEDGMENTS

AUTHORSPaweł Piątek* and Wojciech Grega

References

This research has received a support from the AGH University ofScience and Technology.

[1] Aström K.J., Wittenmark B.,, Prentice Hall, London, 1997.

Computer ControlledSystems

[2] Arzen K-E., Cervin A., Eker J., Sha L., “An Introductionto Control and Scheduling Co-design”. In:

, Australia, Sydney 12 -15 December, 2000.

[3] Franklin G. F., Powell J. D., Emami-Naeini A.,, Addison-Wesley Publishing

Company, London, 1994.[4] Grega W., “Stability of Distributed Control Systems with

Uncertain Delays”. In:,

Międzyzdroje, 2002, pp. 303-307.[5] Middleton R. H., Goodwin G. C:

, Prentice-Hall Internatio-nal, Englewood Cliffs, New Jersey, 1990.

[6] Nilsson J., . Ph.D.Dissertation, Sweden, Lund Institute of Technology,1998.

[7] Piątek P.,-

Ph.D. Thesis (in Polish), Grega W. - supervisor. AGHUniversity of Science and Technology, Department ofAutomatics, Poland, Kraków, 2007.

[8] Piłat A., “Programmable Analog Hardware for ControlSystems Exampled by Magnetic Suspension”. In:

, Kraków, Poland, 14 -16 November, 2005, pp. 143-148.

[9] Sågfors M.,- Ph.D. Dissertation, Process Control Laboratory, Facul-ty of Chemical Engineering, Åbo Akademi University,1998.

[10] Schinkel G., Rantzer A., “Sample Data with Varying Sam-pling Time”. In:

, Porto, Portugal, September, 2001, pp. 624-628.[11] Vaccaro R. J., ,

McGraw-Hill, Inc., New York, 1995.[12] Wittenmark B., Bastian B., Nilsson J., “Analysis of Time

Delays in Synchronous and Asynchronous ControlLoops”. In:

, Tampa, USA, 12 -15 December, 1998.

39 IEEE Con-ference on Decision and Control

FeedbackControl of Dynamic Systems

8 IEEE International Conferenceon Methods and Models in Automation and Robotics

Digital Control and Esti-mation: A Unified Approach

Real-time Control Systems with Delays

Application of Specialized Hardware Archite-ctures for Realization of Time-critical Control Tasks

Proc.Computer Methods and Systems

Optimal Sampled-Data and Multirate Control

Proceedings of European Control Confe-rence

Digital Control a State-Space Approach

Proc. of 37 IEEE Conference on Decision andControl

th

th

th

th

th

th

th

th th


Special issue 61

VOLUME 3, N° 1 2009

Abstract:

1. Introduction: Applicability of Linuxin Real-Time SystemsIn a real-time system there is a conflict between pe-

riodic and aperiodic tasks. Aperiodicity naturally stemsfrom noise, disturbances, delays, and all other unpredic-table phenomena in the real world. A real-time operatingsystem should not enforce strict rules that nature cannotmeet, but rather provide resources that help to smooththe conflicts. Basic approaches are pre-emptivity, buf-fers, and priority rules. However, as a result of pre-em-ptivity, a high-priority task requiring a resource may beblocked to wait for medium-priority tasks that do not holdthis resource. This problem is called priority inversion.

Linux is neither intended, nor designed to supportreal-time tasks. It is a general-purpose operating system,implementing full range of API functions covered by thePOSIX-1003.1 specification. A kernel providing such lar-ge scope of API services cannot meet demands of pre-emptivity and low latency, required in most technologycontrol systems.

To enhance kernel pre-emptivity and reduce kernellatencies, two basic approaches are used:

pre-emptive patches to Linux kernel (Molnar),virtual machines (Hardware Abstraction Layers, RT-Linux, RTAI Linux).

RTLinux kernel implements a Hardware AbstractionLayer inserted between hardware and the Linux kernel.Essentially, it creates a virtual machine that controls theLinux kernel timer interrupt. The RTLinux can switch bet-ween the Linux kernel and other tasks [1], [2], thusmaking possible to solve conflicts between real-timetasks and the Linux kernel. The Hardware AbstractionLayer (HAL) controlling the system is realized in the Linuxkernel space. The system as a whole is simple and fast, butbarriers between real-time task and the non-real-timeLinux kernel are thin, and as a result of that, the real-timepart may easily get out of stability margins required.

Jitter is a variable deviation from ideal timing event.

This paper deals with real-time task jitter measurementunder RTLinux operating system. In the first part, it des-cribes methods and tools developed to measure jitter in theRTLinux environment. In the second part, it is focused ondiscussion of results, obtained on PC hardware, and theirinterpretation.

Keywords: real-time, jitter, latency, measurement, RT-Linux, benchmark, workload effects, saturation method.

�

�

Scheduling jitter is the delay between the time when taskshall be started, and the time when the task is beingstarted. Similarly, interrupt latency is a delay betweenthe time interrupt is triggered and the time when theInterrupt Service Routine is being started. The interruptlatency varies, and therefore, it produces a jitter. Jittersresult from physical phenomena in hardware (noise),from concurrent task processing (realized either in hard-ware or in software), and from passing the code throughdifferent branches (each conditional instruction is a po-tential jitter source). Kernel latency is not stable, butcomposed from various phenomena, most of them (if notall) showing jitters.

RT-Linux is designed as a module to the Linux kernel,and therefore, it could be reasonably supposed, the RT-Linux kernel can suffer from jitters inherited to the Linuxkernel. Hence, thoughtful testing is of prime importance.

Throughout the time, many jitter measuring methodswere developed and published [3], [4]. Periodic task ischaracterized by its starting time of execution and by thelength of execution, while aperiodic task is characterizedby its latency. Interrupt latency is defined as the timefrom generating the interrupt request to (the start of) itsservice routine execution.

Both theory and experience requires, that a systemshall be tested under load. In a technology control sys-tem, the load is caused by the specific application requi-rements. This creates need to test the control systemwith the particular technology plant. On the other hand,benchmarks are valuable in early stages of a design pro-cess to estimate, if a control system intended for the ap-plication will fit its requirements. Therefore, both modelclasses of technology plants and model classes of loadscan be used. As a model load, heavy network or disk loadis often used.

Proctor [3] examines the RTLinux behaviour in a par-ticular application (a motor control), while Dougan [4]provides latencies and jitter examination of individualelementary RTLinux mechanisms without relations totheir interactions with surrounding environment (work-load, controlled technology, control system hardware),and their interactions to each other.

This work presents an approach based on a generalizedapplication program. It is intended as a measuring me-thod tightly connected with application study. Therefore,it can be reasonably assumed, that results will be usefulfor general engineering practice.

2. Existing measurement methods

3. Proposed measurement methods

TASK JITTER MEASUREMENT UNDER

RTLINUX OPERATING SYSTEM

Pavel Moryc, Jindrich Cernohorský


Special issue62

3.1. Generalized data acquisition programRTLinux in tight connection with Linux is intended for

use in systems, that allow both real-time and non-real-time tasks to coexist, and it is typically applied as aninterface between dedicated real-time and non-real-timeIT levels. As a representative case of this class, a gene-ralized data acquisition program has been chosen, sup-plied with diagnostic time stamp outputs.

The application, named RT-golem, contains and inte-grates resources, which make possible to apply a definedworkload to the system, as well as to measure how theload task is executed on the system. It implements bothperiodic and aperiodic tasks.

The RT-golem is a part of an over-all architecturepresented in Figure 1. That contains and integrates re-sources, which make possible to apply a defined work-load to the system, as well as to measure how the loadtask is executed on the system. The RT-golem includes:

periodic task, which is controlled by RTLinuxscheduler,aperiodic task (the Interrupt Service Routine, whichis installed instead the default RTLinux ISR routine).

During initial tests performed with the RT-golem itwas observed that excessive IRQ requests could disruptsystem operation. For that reason, the RT-golem wasstrengthened with overload protection, so it can sustainarbitrary input IRQ rates. Based on the test results, a satu-ration method of measuring interrupt latency was desig-ned, as shown in Figure 2. Interrupts are triggered bya periodic signal supplied from external generator. Theincoming interrupt rate is boosted, till the time betweentwo successive ISR routines starts decreases. When thetime stops decreasing, the IRQ rate reaches its saturationpoint. The minimum time between two successive ISRstarts equals to the interrupt latency. It consists of laten-cy times caused both by hardware and software resources.

Since the saturation imposes the maximum IRQ rateload on the measured system it is capable to accept, themethod is expected to provide comparable results acrossvarious hardware platforms.

�

�

Fig. 1. RT-golem operation.

RT-golem application has been further modified, so itcould be loaded more than once. This creates a possibilityto load the system by more periodic tasks, each with diffe-rent priority, period, time of execution and diagnostictimestamps output. It has evolved to a configurable andflexible simulation tool.

Analysing the measurement results and RTLinux re-sources, it has been recognized, that a measurement tool,which encompasses the whole range of typical RTLinuxresources and provides a deeper insight is needed. Basedon this analysis, the following important RT-Linux charac-teristics have been identified:

precision of the scheduler (measured as task startingtime jitter),interrupt latency time,execution time of typically used API services,pipe write and read operations,shared memory write and read operations,thread switching time,I/O port read and write access time.

The I/O access is also included, because it characte-rizes hardware, and presents the basic method of com-municating with both sensors and actuators.

The generalized application was substantially redesig-ned to form an advanced measurement tool. The advancedversion of RT-golem consists of a periodic task, and aninterrupt service routine. The periodic task includes twothreads. It is possible to set priority and period of boththreads, as well as to disable one or more parts of the task.This way, it is possible to balance the workload that theRT-golem imposes on the system.

A set of comparison measurements has been perfor-med. In particular, the effects of different additional loadon different test systems have been measured, with theload added as follows:

no load,load with copying files(while [true]; do cp /bin/bash ${f}; done),/bin/bash is ca. 70kB in length,load of 15 RT-golem 5.1 tasks

on two test systems,PC Dell GX 280,PC no name.

Fig. 2. ISR latency saturation method.

3.2. Advanced measurement tool: RT-golem

�

�

�

�

�

�

�

�

�

�

�

�

4. Experimental setup


Special issue 63

Fig. 4. Periodic task starting time, PC no name, loaded withcopying files.

Fig. 5. Periodic task finishing time, PC Dell, loaded withcopying files.

Fig. 6. Periodic task finishing time, PC no name, loaded withcopying files.

Fig. 7. Execution time means vs. medians. PC Dell, loadedwith copying files.

dark: meanlight: median

The graphs show that the RT-golem runs smoother onthe Dell PC (Figures 3 and 5), than on the no name PC(Figures 4 and 6). To evaluate the outlying values, figures7 and 8 show the mean vs. median comparison, as well asstandard deviation vs. interquartile range comparison. It

The source code of the RTLinux scheduler containsa comment [5] recommending that this scheduler shouldnot be used for more than 10 tasks. For verification of thisrecommendation, an experiment was designed, where thesystem is heavily loaded by fifteen RT-golem tasks, andjitters of the RT-golem test task are measured. The fifteentasks have been configured as maximum acceptable loadfor the system, that is, the highest load, at which theLinux kernel yet does not start reporting, lost timerinterrupts.

PC Dell is a workstation designed for graphical appli-cations, while PC no name is a low-cost, low-end personalcomputer. Linux kernel has been configured to use only64 MB of RAM memory. Test system configurations arepresented in Table 1.

Because of limited space, only a handful of results canbe presented. The first series of graphs, presented inFigures 3 through 6, show the task instance starting (orfinishing) time, while the second series of graphs (pre-sented in Figures 7 and 8) shows the statistical data. Thetask instance starting time is calculated from the previoustask instance starting time. This means, the starting timedelay impacts two adjacent values. First, the differencebetween the correct and delayed instance is longer, whichcauses the spike up on the graph, and then, the differencebetween the delayed and next correct instance is shorter,which causes the spike down. If both spikes are symme-trical, the second value is okay. The finishing time is cal-culated from the task instance starting time.

Spikes on the relative starting time graphs belowoscillate around 1 msec, because they show schedulingjitter that means, a difference of the actual relativestarting time from the nominal value, which is 1 msec.

Table 1. Test system details.

Fig. 3. Periodic task starting time, PC Dell, loaded withcopying files.

5. Experimental results


Special issue64

stems from definitions of mean and standard deviation,that they are more impacted by outlying values thanmedian and interquartile range.

dark: standard deviationlight: interquartile range

From the results one can conclude that the heavy harddisk operation [3] imposes more load on the system thanthe real-time tasks load. As the load resulting from harddisk operation is quite common in the system according toPOSIX 1003-13 PSE 54 profile, it can be concluded, thata) the scheduler manages to handle more tasks than is

was presumed by its authors,b) the Linux kernel operation significantly influences the

real-time task jitters.

There is a question, whether the real-time characte-ristics of the system (the measured jitter spikes) could besmoother, if the Linux kernel were ported on a CPU desig-ned for real time.

The hardware is built as a layered structure of basichardware resources (disk, memory, processor registers,etc.), and following advanced means (instruction queuesand priority rules). The advanced resources are basicallythe same as the resources used in operating system. Thesehigher-level hardware resources can be seen as a hardwareimplementation of the operating system resources.

A CPU designed for real time (DSP) has different archi-tecture than a CPU designed for general purpose appli-cation. It is unlikely, that it could optimally support a fullrange POSIX 1003-1 compliant kernel.

Based on performed RTLinux and Linux kernel analy-sis, as well as on measured results, it can be reasonablyconcluded that for the RTLinux/Linux operating system,a general-purpose hardware is the optimal hardwareplatform.

Measurements performed at the level of a real-timetask often provide valuable information on task jitters,but only little information on underlying causes. There-fore, it could be useful to create a small and simple HALlayer (module) in the Linux kernel, which intercepts timerinterrupt and possibly other hardware means for a mo-ment, and quickly gets and taps the diagnostic infor-mation needed. Another possible idea is, that such toolcould be integrated into lower (architecture dependent)layer of the RTLinux HAL.

Fig. 8. Execution time means vs. medians. PC Dell, loadedwith copying files.

6. Conclusion and future work

ACKNOWLEDGMENTS

AUTHORSPavel Moryc*, Jindrich Cernohorský

References

This work was supported by the Ministry of Education of theCzech Republic under Project 1M0567.

[1] FSM Labs Inc.,“ “, 2001.[2] I. Ripoll “WP1: RTOS State of the Art Analysis:

Deliverable D1.1: RTOS Analysis”, 2002, OCERA.[3] F.M. Proctor, W.P. Shackleford, “Real-time operating

system timing jitter and its impact on motor control”.In: Proc. SPIE, vol. 4563,

, P.E. Orban (Ed.), 2001,pp. 10-16.

[4] C. Dougan, Z. Mwaikambo, Lies, “Misdirection and Real-time Measurements”, .

[5] RTLinux V.3.1 source code.

- Technical Univer-sity of Ostrava, Faculty of Electrical Engineering andComputer Science, Department of Measurement andControl, Centre for Applied Cybernetics. 17. listopadu 15;708 33 Ostrava-Poruba, Czech Republic. E-mails:[email protected],[email protected].* Corresponding author

Getting Started with RT Linuxet al.,

Sensors and Controls for In-telligent Manufacturing II

C/C++ Users Journal, April 2004


Special issue 65

Abstract:

1. IntroductionThere is an increasing importance and demand for

efficient development of high quality Real-Time Soft-ware-Intensive Control systems (RSIC). Such systemsneed to meet stringent safety and reliability require-ments and often are developed by companies operatingacross national boundaries. To educate modern engineersit is critical to establish a methodology for creation ofmultinational engineering programs, which will producegraduates capable of working efficiently in multidisci-plinary teams that are engaged in international colla-boration on industrial RSIC projects. Such projects typi-cally require conformance to specific national and inter-national standards mandated by regulatory authorities.

Modern systems are heavily software-centric, imple-menting reactive and time-critical software, where safetyis the major issue and the margin for error is narrow.Examples include aircraft avionics, air traffic control,space shuttle control, medical equipment, and nuclearpower stations. It is vital for future software developersto understand basic real-time applications concepts. Thearea of real-time safety-critical control systems is one ofthe most advanced and challenging fields of computerscience and engineering.

The study discussed in this paper is focused on thecreation of an international curriculum framework cen-tred on RSIC. This effort is part of a project on Interna-tional Learning Environment for Real-Time Software-

Due to the heavily software-centric nature of modernreactive and time-critical systems, there is an increasingdemand for efficient development of high quality Real-Time Software-Intensive Control systems (RSIC). The studydiscussed in this paper is focused on the creation of inter-national curriculum framework centred on RSIC - thisimportant aspect of computer-system-control-softwareengineering education. The study explores the mechanismfor involving students from multilingual, geographicallyseparated institutions in a coordinated educational ex-perience. It exposes them to the problems, methods,solution techniques, infrastructure, technologies, regula-tory issues, and tools in the domain of dependable real-time, safety-critical, software-intensive control systems.The ultimate objective is the creation of a model RSICcurriculum, which can be used by engineering schools bothin the USA and the EU.

Keywords: real-time software Engineering, engineeringCurricula.

Intensive Control Systems (ILERT) supported jointly bythe European Commission of the EU and the USA Fund forImprovement of Post-Secondary Education (FIPSE). Thestudy explores the mechanism for involving studentsfrom multilingual, geographically separated institutionsin a co-ordinated educational experience. It will exposestudents to the problems, methods, solution techniques,infrastructure, technologies, regulatory issues, and toolsin the domain of dependable real-time safety-criticalsoftware-intensive control systems. The ultimate objec-tive is the creation of a model RSIC curriculum, which canbe used by engineering schools both in the USA and theEU. This objective addresses the nations' needs for re-searchers and developers of real-time safety-criticalsystems who may be engaged in projects spanning thenations' boundaries and promoting a student-centred,transatlantic dimension to higher education andtraining

International collaboration and globalisation is a keyelement for the nations to come together in a peacefulway. Creation of common educational experience allowsyoung engineers to find commonalities; it promotesteamwork and collaboration in joint projects crossing thenations' boundaries. Specifically, in the area of RSIC sys-tems used in a regulated industry, it is critical to be fami-liar with the variety of regulations, standards, and guide-lines required for designing, implementing and appro-ving software-intensive systems. The proposed studycreates a viable vehicle for such solutions.

There is a clear need to prepare professionals forinternational collaboration. Understanding critical issu-es related to RSIC, the tools and techniques used,and documentation required for approval of systems ina regulated industry is critical for the future globalprojects. The ILERT project is meant to support suchinternational collaboration and consensus building.

.

There exists well-established guidance for the deve-lopment of computing curricula [1, 2] and there is a varie-ty of excellent engineering offered in colleges and uni-versities on both sides of the Atlantic. However, at thistime, there is no international, interdisciplinary curricu-lum that directly focuses on real-time control systems,dependable software development, safety, reliability, andthe certification issues in highly regulated industries likeaerospace, medicine, transportation, and nuclear energy.In addition, there is no curriculum that includes globa-lisation aspects of the modern engineering profession.

2. Global aspects of the software industry

3. Curricular issues

ILERT - INTERNATIONAL LEARNING ENVIRONMENT

FOR REAL-TIME SOFTWARE-INTENSIVE CONTROL SYSTEMS

Andrew J. Kornecki, Thomas B. Hilburn, Wojciech Grega, Miroslav Sveda, Jean-Marc Thiriet


Special issue66

The current study will lead to the design of such curricu-lum framework, identification of implementation andassessment mechanisms, collection of data necessary toevaluate the process, and guidelines for expansion of theproposed approach to other engineering programs. Theseobjectives are consistent with the following comple-mentary goals:

Identify a methodology for design and implemen-tation of a transatlantic, multidisciplinary enginee-ring program.Stimulate students to follow careers by encouragingthem to consider the area of real-time safety-criticalcontrol systems and expose them to opportunities ofinternational collaboration.Encourage the exchange of staff and students bet-ween collaborating institutions.Offer multidisciplinary and multicultural experienceto students who would not otherwise have suchopportunities.Provide a forum for faculty exchange of ideas on theissues of curricula building, laboratory experiments,and assessment activities.Create a foundation for Internet-based laboratoryeducational experiences, which will expose studentsfrom different countries to tools, methods, and tech-niques used in the creation of highly dependable safe-ty critical systems for regulated industry.Stimulate the teaching staff of the European partnersto develop and introduce English versions of lecturesand teaching materials.Foster a strong technological and education research base.

The two-year study, supported by the US Departmentof Education Fund for Improvement of Post-SecondaryEducation (FIPSE) and the EU European Commission, isdedicated to the creation of a unique RSIC curriculumfocusing on real-time software-intensive control andsafety-critical dependable systems. The ILERT projectinvolves international collaboration of four universities,which allows for exploration of the global implication ofoffering transferable engineering curricula. The partnersinclude one American and three European universitieslocated in three different EU countries, where English isnot the language of instruction (Poland, France, CzechRepublic). These partners have adequate educational/research potential; and, through their industry and inter-national outreach, they also recognize the needs of thecurrent and prospective labour market for real-time con-trol education, both in Europe and in the USA. They havepublished on the issues related to engineering curriculaimprovement [3-6, 8-10].

A two-pronged approach is used. The first includesactive partners' collaboration on identification of thelearning objectives and outcomes, description of the cur-riculum core and supporting units, development of guide-lines on the implementation and assessment, identifi-cation of the technology infrastructure, and the descrip-tion of faculty and staff requirements, pedagogy anddelivery concepts, accreditation issues and constraints,etc. On-site research by the project faculty and selectedstudents has been enhanced by frequent communications

�

�

�

�

�

�

�

�

4. Activities

and dedicated working sessions at the partners' sites. Thesecond part of the approach is a practical case study onhow the proposed framework can be implemented by thepartner institutions. Identification of the existing oreasily modifiable courses, which can be used as units inthe RSIC curriculum, has been attempted. A description ofthe laboratory infrastructure, necessary administrativeprocedures (admission, scheduling, and credit transfer),an assessment methodology, and experimental develop-ment and delivery of a selected RSIC unit to partner insti-tutions were undertaken. This experimental concurrentdelivery, still in planning stage, will engage on-site stu-dents only. The knowledge gained from the experienceand relevant observations constitute a base for establi-shing a dedicated international transatlantic program inReal-Time Software-Intensive Control and may serve asa framework for development of other global engineeringcurricula.

The project deliverables include:Analysis of industry requirements for graduates of theRTSC domain;International, interdisciplinary Real-Time SoftwareIntensive Control Systems curriculum framework;Design for a selected unit supporting the proposedRSIC curriculum with the draft of lecture materials andlaboratory handouts;Plan and pilot implementation of a laboratory infra-structure allowing students to actively participate inclass activities and experiments on a remote basis;Experimental concurrent delivery of the designed unitat the four partner sites;Identification of activities and data for program asse-ssment and evaluation, and those issues and elementsrequired to consider program accreditation;Reflection on a process and methodology for creationof multidisciplinary, transatlantic engineering pro-grams, including guidelines for extension of theapproach to other engineering programs.

Feedback from future employers of graduates is cri-tical to the design of a curriculum, which fully matchesthe continuously changing job market demands. A surveywas designed to get this feedback from a specific sector ofindustry regarding what employers expect graduates tohave in terms of skills and attitudes, as well as knowledgeof technical topics. This Internet based survey was soli-cited from a representative sample of industry engaged inreal-time software-intensive control systems. The collec-ted data were analysed and the results were used to helpidentify academic program educational outcomes andobjectives thus preparing a base for creation of a newcurriculum framework.

The respondents reflected an international composi-tion of the ILERT project representing four countries:Czech Republic, France, Poland and USA. It needs to benoted, that we had relatively weak response rate upon theinitial e-mail solicitation. The reason was that in manycases the mailing was intercepted by spam filters or therespondents were too busy to commit about 15-20 minu-tes to fill the survey. Occasionally, the survey reached anindividual who was not prepared to provide the requested

�

�

�

�

�

�

�

5. Analysis of industry requirements


Special issue 67

panies are listed in Table 1.The survey, designed by the ILERT project partners,

was placed on a web server and participants were invitedvia e-mail, phone, and personal contact to login to thesurvey site and provide their responses. The surveyincluded two main categories: Part A and Part B. Part

information. Repeated contacts and follow-ups allowed usto receive enough data to consider the results as valid.Eventually, as a response to over 370 solicitation wereceived 43 responses (11% response rate). We are grate-ful for the companies who took part in the survey andprovided us with a valuable feedback. The names of com-


Company Name

Avidyne, Raytheon, Hawker Beechcraft Corporation, Stuart W. Law Company, Boston Scientific,Teledyne Controls, Boeing, Honeywell Aerospace, Hamilton Sundstrand.

CSN-STANEL Automatyka, ABB Corporate Research, Astor, Abis, RAControls, InTeCoFEV Polska,Pumpa, Tarbonus, Multiprojekt, Computer Systems for Industry, ComArch, INVENTIA, MPLTechnology.

Tescan, ANF DATA, B+R Automatizace, Honeywell, Freescale Czech Republic, ADC Czech Republic,CAMEA, Flextronics Design, ANeT Ltd., Schneider Electric CZ.

CIRTEM, National Research and Safety Institute, ST Microelectronics, IRSN Radioprotection andNuclear Safety French TSO, Leroy Somer, Airbus S.A., Euro-Systems.

Part B Items

B. 1. Good background in mathematicsB. 2. Familiarity with a specific application domainB. 3. Knowledge of control theory, algorithms and

applicationsB. 4. Knowledge of system specification and design

methodsB. 5. Knowledge of hardware design and development

concepts, methods and toolsB. 6. Knowledge of software design and development

concepts, methods and toolsB. 7. Knowledge of formal methods applied to

system developmentB. 8. Experience with hardware development

platforms (e.g. FPGA, PLC, microcontrollers,I/O devices)

B. 9. Knowledge of networking components,topologies and communication protocols

B. 10. Proficiency in software program construction(programming language)

B. 11. Understanding the concept of real-timesystems (timing, scheduling, RTOS services)

B. 12. Familiarity with software development toolsand development environments (integrateddevelopment environment - IDE, compilers/interpreters, simulators, emulators, code/testgenerators)

B. 13. Knowledge of system development process andproject management

B. 14. Experience with hardware/software integration,including testing and verification

B. 15. Knowledge of quality control, validation,verification, and certification (e.g. fordependable systems)

Country

USA (12)

Poland (14)

Czech Republic (10)

France (7)

Part A Items

A.1. Work as a part of a multidisciplinary teamA.2. Analyse, understand and define the problemA.3. Think independently and search for solutions

A.4. Make oral presentations

A.5. Write technical reports and papers

A.6. Communicate with people and presentarguments

A.7. Communicate in a foreign language

A.8. Lead a team

A.9. Understand value and cost

A.10. Experience international, social, cultural andpolitical issues

Table 1. ILERT Survey Companies.

Table 2. Industrial Survey Items.

Special issue68

A was intended to assess the importance of general skills,capabilities and attitudes of engineering school gradu-ates when they enter the job market. Part B includeditems related to specific technical areas and skills. Theitems in Part A and Part B are listed in Table 2.

In both, Part A and Part B, the items could be rated as:Essential, Important, Unrelated, and Unimportant, witha possibility to provide comments. In addition to selec-ting responses in Parts A and B, the survey included PartC, where responders were asked to create a “wish list”, i.e.to rank the first three items in each category according totheir importance for the need of their company. In Part D,the survey asked respondents to fill information regardingthe company profile, size, type of projects, etc. This infor-mation was treated confidentially to be used only toanalyse and create aggregated results.

A detailed analysis of the results is contained in [7].Figure 1 depicts the relative ranking of the importance ofthe Part A Survey items. The highest scores received itemsrelated to understanding, problems solving, creativityand teamwork. The responses underscore the need foremployees capable of communicating and using moderntechnologies. Figure 2 shows the ranking for the Part BSurvey items. The highest score received items related toknowledge of methods and techniques related to softwareand system design and development. The responses un-derscore the industry need for employees that could beefficient from day one when facing new project and adap-ting to new development environment.

The industrial survey results verified the generallyagreed upon set of non-technical skills and behavioursexpected from engineering school graduates (oral andwritten communications, professional ethics, team skills,etc.). More importantly, the survey provided a startingpoint for designing a specific program curriculum byhelping the ILERT investigators to identify the technicalknowledge areas and skills required from graduating stu-dents. Discussion and analysis of the survey results led tothe definition of a general set of RSIC program educa-tional objectives and outcomes, defined in terms of theexpected graduates' proficiency, specifying the profile ofgraduates and their competencies. We used the defini-tions of Program Educational Objectives (PEO) and Pro-gram Outcomes provided by the Accreditation Board ofEngineering Technology (ABET). PEO are broad state-ments that describe the career and professional accom-plishments that the program is preparing graduates toachieve. PO are narrower statements that describe whatstudents are expected to know and be able to do by thetime of graduation.

6. Educational objectives and outcomes

Fig. 1. Ranking of Part A Items.

Fig. 2. Ranking of Part B Items.

The graduates of any high quality-engineering prog-ram are expected to meet the following general fourprogram educational objectives [A-D]:[A] Demonstrate professionalism in their work and

grow professionally through continued learningand involvement in professional activities.

[B] Contribute to society by behaving ethically andresponsibly, and by incorporating knowledgeof history and culture into one's professionaldecisions.

[C] Communicate effectively in oral, written, and new-ly developing modes and media.

[D] Assume a variety of roles in teams of diverse mem-bership.

The major areas of proficiency for the graduates ofan international RSIC program (3-4 years of university/college education) have been identified based on theresults of industry surveys and discussion at the consor-tium meetings. These areas expand the general objectiveswith three additional [E-G] specific to the RSIC program:[E] Demonstrate understanding of analysis and design

as applied to modern software-intensive controlsystems.

[F] Demonstrate understanding of processes and tech-niques and the role of modern engineering toolsnecessary to engineering practice as applied forcreation of software-intensive systems.

[G] Demonstrate understanding of quality assuranceand hardware/software integration for creation ofsafe and dependable systems.

The Program Outcomes are characteristics of the gra-duating students that can be evaluated at the programcompletion. They include ability to:1. … apply knowledge of mathematics, science, and

engineering to solve technical problems;2. … design and conduct experiments, and an ability

to analyse the data;3. … analyse and understand the operation of a con-

trol system or component to meet desired needs(feedback, stability, system dynamics, robust-ness);

4. … apply advanced software engineering tech-niques to implement real-time concepts (timing,scheduling, concurrency, synchronization);

5. … support assurance of the quality of a software-intensive system across its lifecycle includingassurance of its dependability using establishedstandards and guidelines (verification, validation,testing, safety, reliability, security, standards,


Special issue 69

guidelines);6. … integrate hardware and software on variety of

platforms with various interfaces and protocols;7. … use a defined lifecycle process in development

of software-intensive system;8. … function on multi-disciplinary teams;9. … understand professional and ethical respon-

sibility;10. … communicate effectively;11. … work effectively in an international environ-

ment;12. … understand of the impact of engineering

solutions in a global and societal context;13. … recognize the need for and engage in life-long

learning including ability to pursue graduatestudies;

14. … understand contemporary issues in softwareengineering, especially in the RSIC area.

The program outcomes help to identify the topicsnecessary for preliminary curriculum design. It is criticalto understand the role of general education requirements,which complements the engineering facet of the curricu-lum and facilitates the main objective of university mis-sion: to produce valuable and contributing members ofthe society.

Quantitative and qualitative indicators need to beused to assess the degree of fulfilment of the plannedobjectives and outcomes in the proposed time-frame,based on the detailed plan of work with specific timelineand detailed deliverables. There are three categories ofindicators, related to the output, the results, and theimpact. The output indicators provide information elabo-rating the immediate and short-term effects resultingfrom the planned execution of the project. These includecurricula design, educational events, external institutionsthat have benefited from the project outputs, createdartefacts, and presentations shared with external audien-ces. The results indicators provide information on the pro-ject output and the immediate results: new cooperativeinitiatives, published papers, position documents genera-ted, etc. The impact indicators measure the long-termeffects: institutions implementing the proposed frame-work, learning tools and services created by the project,citations and references to the project documents andpapers, third-party references to project outcomes, etc.

Real-time software-intensive safety-critical controlsystems represent a rather narrow and specific educationand research area. Not many courses are offered at theundergraduate and graduate level, since appropriate co-verage requires a significant amount of diverse domainknowledge difficult to include in typically overloadedcomputer science and engineering programs.

Nearly all-engineering disciplines have segments en-gaged in creation of RSIC systems. The systems are imple-mented worldwide, which requires a well-prepared work-force of scientists and engineers, who can cooperativelyaddress issues in a multi-disciplinary and international

7. Assessment

8. Conclusions

fashion. The ILERT project is intended to strengtheninternational co-operation and the global links in engi-neering education. An interdisciplinary specialization inRSIC was selected to produce not only a number of educa-tional artefacts in a domain in high demand by industry,but also (what is more important) a process and a metho-dology for creation of engineering programs with a com-patible quality assurance and assessment process. Thegraduates of such programs will be better prepared towork on projects requiring interdisciplinary and multicul-tural viewpoints. This enhances mobility of the futureworkforce and facilitates their advancement and careerchanges.

The objective of the proposed activity is not only toserve the critical population of safety-critical real-timecontrol system developers, but also to disseminate resultsand provide guidelines to a broader audience of enginee-ring education faculty. The project will capture the pro-cess and methodology used by this multidisciplinaryand geographically diverse activity for potential re-useby others. The collected observation and data will pro-vide the base and guidelines for future implementa-tion of complete coordinated multinational engineeringprograms.

- Embry RiddleAeronautical University, Daytona Beach FL, USA. E-mails:[email protected], [email protected].

- AGH University of Science and Tech-nology, Krakow, Poland. E-mail: [email protected].

- Brno University of Technology, Brno,Czech Republic. E-mail: [email protected].

- Laboratoire d'Automatique de Gre-noble, Grenoble, France. E-mail:[email protected].* Corresponding author

ACKNOWLEDGMENTS

AUTHORSAndrew J. Kornecki*, Thomas B. Hilburn

Wojciech Grega

Miroslav Sveda

Jean-Marc Thiriet

References

The authors acknowledge the Atlantis Program support for thework on the ILERT Project (http://www.ilert.agh.edu.pl) fromthe European Commission (EC grant: 2006-4563/006 001) andthe US Department of Education FIPSE Program (US grant:P116J060005). The authors appreciate also contribution of ourcolleagues Ondrej Rysavy and Petr Matousek (BUT).

[1] Computer Engineering 2004,

, ACMIEEE Comp. Society, December 2004.(http://www.acm.org/education/CE-FinalReport.pdf )

[2] Software Engineering 2004,

ACM IEEEComp. Society, August 2004.(http://www.acm.org/education/curricula.html )

[3] Grega W., “Towards the Bologna-BMD Model: Poland”,in:

(J.M. Thiriet, editor), Nancy

Curriculum Guidelines forUndergraduate Degree Programs in Computer Enginee-ring, The Joint Task Force on Computing Curricula

Curriculum Guidelines forUndergraduate Degree Programs in Software Engineering,The Joint Task Force on Computing Curricula,

Towards the Harmonization of Electrical and Infor-mation Education in Europe


Special issue70


University 2003, ISBN 972-97738-3-1, pp. 152-158.[4] Hilburn T.B., Humphrey W.S., “The Impending Changes

in Software Education”, , vol. 19, no. 5,September / October, 2002.

[5] Kornecki A.J., “Real-Time Computing in Software Engi-neering Education”. In:

, Austin, TX, March 2000, pp. 197-198.[6] Kornecki A.J., “Real-Time Systems Course in Undergra-

duate CS/CE Program”, ,CD-ROM Supplement, vol. 40, no. 4, November 1997,pp. 295-296.

[7] Pilat A., Kornecki A.J., Thiriet J. M., Grega W., Sveda M.,“Industry Feedback on Skills and Knowledge in Real-Time Software Engineering”. In:

, June 2008. (accepted forpublication).

[8] Thiriet J.M., Martins M.J., Editors, Monograph:

- Ed. EAEEIE, August2003, 350 pages. ISBN, book version: ISBN 972-97738-2-3, ISBN: CD-ROM version: ISBN 972-97738-3-1.

[9] Thiriet J.M., Robert M., Lappalainen P., Hoffmann M.,Martins M. J., Seoane A., “Toward a Pan-European Vir-tual University in Electrical and Information Engi-neering”, , May 2002, vol.45,no. 2, pp. 152-160.

[10] Whetten F.L., Kornecki A.J., “Distance Teaming: A Bi-located Undergraduate Program in Computer Enginee-ring”. In:

, Madison, WI, 1997,pp. 361-364.

IEEE Software

Proceedings of 13 SEE&T Confe-rence

IEEE Transactions on Education

Proceedings of 9EAEEIE Annual Conference

Towardsthe Harmonization of Electrical and InformationEngineering Education in Europe

IEEE Trans. on Education

Proceedings of 13 Annual Conference onDistance Teaching and Learning

th

th

th

VOLUME 3, N° 1 2009

Special issue 71

�

Source: http://www.engc.ac.kr/english/ Image source: www.aving.net

Source: hismar.ncl.ac.uk / www.hismar.eu and Rzeczpospolita.pl

�

Blooming robots, dancing flowers

Scientists from Gwangju's Chonnam National Universityhave developed a robot plant that emits oxygen, moisture,insecticidal pesticides, and fragrance. It also has all kineticfunctions and responds at stimuli from outside - like realplants. When a person or animal (or another moving object)approaches within a 40 cm radius of the robot, the budscome into bloom. Robotic plant returns to its original statewhen objects leave - it is enabled by using SMA - ShapeMemory Alloy to make it. The flower react also for soundslouder than usual, including music, and light. It is possiblebecause a supersonic sensor that perceives the motion andturns the steam towards person, and the flower opens.Moreover, the plant can dance when music is played.Robotic pot plant is 130 cm tall and 40 cm in diameter andconsists of a pot, a stem, and five buds of a flower whichlooks like a rose of Sharon (a national flower of SouthKorea). You can have a "Roses robots garden" by usinga networking system. However flower robots are not new -some have already been developed in the U.S., this roboticplant is currently the most advanced. Retail price is notquoted. Professor Park Jong-Oh and his team struggles withautomatically change of flowers' colour. The robotic plantdebuted in November at a Robot Festival at Seoul's COEXMall.

Marine barber

Ships also need shaving their "beards". Scientist from 10 countries under University of Newcastle co-ordination iscurrently constructing an autonomous robot designed for cleaning the hulls of the ships. European Union assigned1.2 million Euros for Hull Identification System for Marine Autonomous Robotics programme - from which a robot is calledHISMAR. More or less once a year a ship has to be "shaved" - all crustacea, algae, seaweeds and shells, which have piloseda hull must be scraped. If not, a ship has much bigger resistance (up to 40%) to the water and floats noticeable slower(1-2 knots, which means from 1,9 to 3,8 km/h). Extra fuel's cost (more even 20 percent) caused by this effect amounts to9 billion dollars. Because the "shaving" operation is long-term and big ships need repair dock for this, special anti-sprouting paints are used; nevertheless paints' ingredients, like lead, copper or tin, are toxic for natural environment.Year ago EU has strictly forbidden ships painted tin-based dye to call a European harbour.

HISMAR is composed of modules, weights less than 180 kg, adheres to hull due to magnetic systems (enduring weight up350 kg) and moves on 4 small wheels. A small computer embedded into robot draws its route. Cameras transmit view ofsurface and enable to detect damages of ship's skin plate. Robot cleans the hull by ejecting a water jet under 200-barpressure. Dirty water with removed parasites is pumped to special chamber on the ship, where is undergone purification.

HISMAR can be set in motion during every stopover, even on the sea and with working engine (if ship floats slowly).Whole programme with a prototype was shown in Hamburg, Germany, during marine exhibition SMM 2008 Shipbuilding,

Machinery and Marine Technology.

Focus on new


IN THE SPOTLIGHT

VOLUME 3, N° 1 2009

In the spotlight72

�

�

Source: http://trendy.nikkeibp.co.jp/article/news/20080924/1019000/and http://www.pinktentacle.com/

Image: courtesy of Murata Manufacturing Co. Ltd.

Source: University of Bath and http://www.sciencedaily.com/releases/2008/12/081204074810.htm

Images: courtesy of University of Bath

Murata Boy has a female friend

More and more insect-like robots

Electronic parts maker Murata Manufacturing Co., Ltd., crea-tors of the popular Murata Seisaku-kun (a.k.a. “Murata Boy”) robotbicyclist, have developed a self-balancing robot unicyclist named“Murata Seiko-chan”. The 50-centimeter tall, 5-kilogram Seiko-chan, which Murata says is modelled after a female kindergartenerfeatures a pair of gyro sensors that detect her posture angle.A single wheel moves the robot forward and back, and a rotatingflywheel in the chest helps turn the unicycle left and right andmaintain balance. In addition to ultrasonic sensors detecting andmeasuring the distance to potential obstacles, Seiko-chan isequipped with built-in Bluetooth capabilities and an embeddedcamera that transmits live video. According to Murata's pressrelease, Seiko-chan is described as Seisaku-kun's younger paternalcousin.

First robot that can jump like a grasshopper and roll like a ball was invented by Rhodri Armour, a PhD student at BathUniversity's Centre for Biomimetic & Natural Technologies, UK. One of the major challenges that face exploration robots isbeing able to move over rough terrain. Jumping in a similar way to the grasshopper, robot can overcome bigger obstaclesthan conventional robot with wheels; it is also much cheaper to construction than robot with legs. "Jollbot" is cheap, light(it weights less than 1 kg), small and flexible, meaning it's not damaged when landing after jumping. The “Jollbot” isshaped like a spherical cage, which can roll in any direction, giving it the manoeuvrability of wheels without the problem ofoverturning or getting stuck in potholes."Before jumping, the robot squashes itsspherical shape. When it is ready, it releasesthe stored energy all at once to jump toheights of up to half a metre", Mr Armoursaid. The components of the robot were ma-de by rapid prototyping technology, similarto that used by the RepRap machine pionee-red by the University, which builds parts by"printing" layers of plastic on top of eachother to produce a 3D object.

Apparently Jollbot can be used in land survey work. Inventor hopesthat his brainchild will also play key role in future space exploration.


73In the spotlight


February

March

April

20 – 22 ICCMS 2009

20 – 22 ICECT 2009

07 – 09 ICFN 2009

07 – 09 ICDIP 2009

08 – 10 ICCAE 2009

09 – 11 INTED 2009

25 – 27 CICAR 2009

26 – 28 INCAMA 2009

27 – 29 ICWCSN 2009

30 – 2 April

02 – 04 ICC 2009

03 – 05 ICIME 2009

– International Conference on Computer Modeling and Simulation, Macau, Macau.http://www.iccms.org/index.htm

– International Conference on Electronic Computer Technology, Macau, Macau.http://www.icect.org/

– International conference on Future Networks, Bangkok, Thailand.http://www.icfn.org

– International conference on Digital Image Processing, Bangkok, Thailand.http://www.icdip.org

– International Conference on Computer and Automation Engineering, Bangkok,Thailand.http://www.iccae.org/index.htm

– International Technology, Education and Development Conference, Valencia,Spainhttp://www.iated.org/inted2009

– 6 International Conference on Computational Intelligence, Control, Auto-mation and Robotics Bangalore, India.http://www.waset.org/wcset09/bangalore/cicar/

– International Conference on Advanced Manufacturing and Automation,Krishnankoil, Tamil Nadu, India.http://www.kalasalingam.ac.in/mech/incama2009.html

– International Conference on Wireless Communication and Sensor Networks,Buenos Aires, Argentina.http://www.waset.org/wcset09/buenosaires/icwcsn/

IEEE Symposium on Computational Intelligence, Nashville, Tennessee, USA.http://www.ieee-ssci.org

– International Conference of Computing in Engineering, Science and Informatics,Los Angeles, California, USA.http://www.fullerton.edu/icc2009/

– International Conference on Information, Management and Engineering, KualaLumpur, Malaysia.http://www.icime.org/index.htm

th

EVENTSWINTER-SPRING 2009

VOLUME 3, N° 1 2009

Events74


03 – 05 ICFCC 2009

08 – 10 CATA 2009

15 – 16

27 – 29 ITNG 2009

28 – 30 ICEUC 2009

29 – 30 ICICSE 2009

27 – 29 ICCIT 2009

23 – 26 ICORR 2009

– International Conference on Future Computer and Communication, KualaLumpur, Malaysia.http://www.icfcc.org

– 24 International Conference on Computers and Their Applications, New Orleans,Louisiana, USA.http://www.isca-hq.org/CATA-2009-CFP.pdf

RoboBusiness, Boston, Massachusetts, United States.http://www.robobusiness.com

– 6 International Conference on Information Technology: New Generations,Las Vegas, Nevada, USA.http://www.itng.info

– International Conference on Embedded and Ubiquitous Computing Rome, Italy.http://www.waset.org/wcset09/rome/iceuc/

– International Conference on Intelligent Control Systems Engineering Rome,Italy.http://www.waset.org/wcset09/rome/icicse/

– International Conference on Computer and Information Technology, Tokyo,Japan.http://www.waset.org/wcset09/tokyo/iccit/

– IEEE 11 International Conference on Rehabilitation Robotics, KyotoInternational Conference Center, Japan.http://www.icorr2009.org/

th

th

th

May

June

EVENTSWINTER-SPRING 2009

VOLUME 3, N° 1 2009

75Events

jamris 2009 vol 3 no 1

Documents

lancaster university

canadacardiff university

usabengurion university

portugalbournemouth

university wrzburg

tokyo institute of technology

mexicofeng chia university

industrial research