JOURNAL of AUTOMATION, MOBILE ROBOTICS & INTELLIGENT SYSTEMS
Editor-in-Chief Janusz Kacprzyk
Executive Editor: Anna Ładan aladan@piap.pl
(Systems Research Institute, Polish Academy of Sciences; PIAP, Poland)
Associate Editors: Mariusz Andrzejczak (PIAP, Poland) Katarzyna Rzeplińska-Rykała (PIAP, Poland)
Co-Editors: Dimitar Filev (Research & Advanced Engineering, Ford Motor Company, USA)
Kaoru Hirota
Webmaster: Tomasz Kobyliński tkobylinski@piap.pl
(Interdisciplinary Graduate School of Science and Engineering, Tokyo Institute of Technology, Japan)
Witold Pedrycz
Proofreading: Urszula Wiączek
(ECERF, University of Alberta, Canada)
Roman Szewczyk (PIAP, Warsaw University of Technology, Poland)
Editorial Office: Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, POLAND Tel. +48-22-8740109, office@jamris.org
Copyright and reprint permissions Executive Editor
Editorial Board: Chairman: Janusz Kacprzyk (Polish Academy of Sciences; PIAP, Poland) Plamen Angelov (Lancaster University, UK) Zenn Bien (Korea Advanced Institute of Science and Technology, Korea) Adam Borkowski (Polish Academy of Sciences, Poland) Wolfgang Borutzky (Fachhochschule Bonn-Rhein-Sieg, Germany) Oscar Castillo (Tijuana Institute of Technology, Mexico) Chin Chen Chang (Feng Chia University, Taiwan) Jorge Manuel Miranda Dias (University of Coimbra, Portugal) Bogdan Gabryś (Bournemouth University, UK) Jan Jabłkowski (PIAP, Poland) Stanisław Kaczanowski (PIAP, Poland) Tadeusz Kaczorek (Warsaw University of Technology, Poland) Marian P. Kaźmierkowski (Warsaw University of Technology, Poland) Józef Korbicz (University of Zielona Góra, Poland) Krzysztof Kozłowski (Poznań University of Technology, Poland) Eckart Kramer (Fachhochschule Eberswalde, Germany) Andrew Kusiak (University of Iowa, USA) Mark Last (Ben–Gurion University of the Negev, Israel) Anthony Maciejewski (Colorado State University, USA) Krzysztof Malinowski (Warsaw University of Technology, Poland)
Andrzej Masłowski (PIAP, Poland) Tadeusz Missala (PIAP, Poland) Fazel Naghdy (University of Wollongong, Australia) Zbigniew Nahorski (Polish Academy of Science, Poland) Antoni Niederliński (Silesian University of Technology, Poland) Witold Pedrycz (University of Alberta, Canada) Duc Truong Pham (Cardiff University, UK) Lech Polkowski (Polish-Japanese Institute of Information Technology, Poland) Alain Pruski (University of Metz, France) Leszek Rutkowski (Częstochowa University of Technology, Poland) Klaus Schilling (Julius-Maximilians-University Würzburg, Germany) Ryszard Tadeusiewicz (AGH University of Science and Technology in Kraków, Poland)
Stanisław Tarasiewicz (University of Laval, Canada) Piotr Tatjewski (Warsaw University of Technology, Poland) Władysław Torbicz (Polish Academy of Sciences, Poland) Leszek Trybus (Rzeszów University of Technology, Poland) René Wamkeue (University of Québec, Canada) Janusz Zalewski (Florida Gulf Coast University, USA) Marek Zaremba (University of Québec, Canada) Teresa Zielińska (Warsaw University of Technology, Poland)
Publisher: Industrial Research Institute for Automation and Measurements PIAP
If in doubt about the proper edition of contributions, please contact the Executive Editor. Articles are reviewed, 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.
All rights reserved ©
1
JOURNAL of AUTOMATION, MOBILE ROBOTICS & INTELLIGENT SYSTEMS VOLUME 3, N° 1, 2009
CONTENTS REGULAR PAPERS 40
3
Using pre-emption for dependable urban vehicle traffic T. Letia, S. Barbu, F. Dinga
Reachability of fractional positive continuous-time linear systems T. Kaczorek
46
8
Incorporating fault tolerance into component-based architectures for embedded systems S. Lu, W. A. Halang
Pointwise completeness and pointwise degeneracy of linear continuous-time fractional order systems T. Kaczorek, M. Busłowicz
12
52 Fault sensitivity of explicit DMC and GPC algorithms P. Gawkowski, M. Ławryńczuk, P. Marusak, J. Sosnowski, P. Tatjewski
Stability analysis of linear continuous-time fractional systems of commensurate order M. Busłowicz
57
SPECIAL ISSUE SECTION Dependability and Safety of Real-Time Computer Systems Editors: Wojciech Grega, Andrew J. Kornecki, Janusz Zalewski
Speed analysis of a digital controller in time critical applications P. Piątek, W. Grega
62 Task jitter measurement under RTLinux operating system
20
EDITORIAL W. Grega, A. J. Kornecki, J. Zalewski
66 ILERT - international learning environment for realtime software-intensive control systems A. J. Kornecki, T. B. Hilburn, W. Grega, M. Sveda, J-M. Thiriet
23 Reusing Verilog Designs in the Synchronous Language Esterel M. Leuchter, S. Tyszberowicz, Y. A. Feldman
DEPARTMENTS
30 Towards the safety verification of real-time systems with the coq proof assistant O. Tveretina
33
IN THE SPOTLIGHT 74
Improving dependability of automation for free electron laser FLASH B. Kosęda, T. Szmuc, W. Cichalewski
2
72
EVENTS
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
REACHABILITY OF FRACTIONAL POSITIVE CONTINUOUS-TIME LINEAR SYSTEMS Received 18th April 2008; accepted 9th June 2008.
Tadeusz Kaczorek
Abstract: A new class of fractional linear continuous-time linear systems described by the state equation is introduced. The solution to the state equations is derived using the Laplace transform. Necessary and sufficient conditions are established for the internal and external positivity of the fractional systems. Sufficient conditions are given for the reachability of the fractional positive systems. Keywords: fractional, positive, continuous-time, linear, system, reachability.
1. Introduction In positive systems inputs, state variables and outputs take only non-negative values. Examples of positive systems are industrial processes involving chemical reactors, heat exchangers and distillation columns, storage systems, compartmental systems, water and atmospheric pollution models. A variety of models having positive linear systems behaviour can be found in engineering, management science, economics, social sciences, biology and medicine, etc. Positive linear systems are defined on cones and not on linear spaces. Therefore, the theory of positive systems is more complicated and less advanced. An overview of state of the art in positive systems is given in the monographs [2, 5]. An extension of positive systems are the cone systems [6, 9]. The notion of cone systems was introduced in [6]. Roughly speaking cone system is a system obtained from positive one by substitution of the positive orthants of states, inputs and outputs by suitable arbitrary cones. The realization problem for cone systems has been addressed in [6, 9]. The first definition of the fractional derivative was introduced by Liouville and Riemann at the end of the th 19 century [12, 10, 20]. This idea has been used by engineers for modelling different process in the late 1960s [28-30]. Mathematical fundamentals of fractional calculus are given in the monographs [10, 12, 20, 13, 19]. The fractional order controllers have been developed in [18, 22]. A generalization of the Kalman filter for fractional order systems has been proposed in [26]. Some others applications of fractional order systems can be found in [1, 15-17, 3, 11, 23, 24, 27, 28, 25]. In [14] a method for computation of the impulse responses from the frequency responses for the fractional standard (nonpositive) discrete-time linear systems has been given. Fractional polynomials and nD systems have been investigated in [4].
In this paper a new class of fractional positive continuous-time systems described by the state equations will be introduced and the necessary and sufficient conditions for the internal and external positivity will be established. The paper is organized as follows. In section 2 using the Caputo definition and Laplace transform the solution to the state equations of the fractional systems is derived. The necessary and sufficient conditions for the internal and external positivity of the fractional systems are established in section 3. In section 4 the reachability of the positive fractional systems is investigated. Concluding remarks are given in section 5. To the best knowledge of the author the positive fractional continuous-time linear systems have not been considered 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 nonnegative entries will be denoted by and A matrix A with nonnegative entries will be also denoted by . The set of nonnegative integers will be denoted by and the identity matrix by .
2. Continuous-time fractional linear systems and their solutions In this paper the following Caputo definition of the fractional derivative will be used [10, 20]
(1)
where
is the order of fractional derivative and .
Consider the continuous-time fractional linear system described by the state equations (2a) (2b) where input and output vectors and .
are the state,
Theorem 1. The solution of equation (2a) is given by (3) Regular papers
3
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
where (4)
N° 1
2009
Remark 2. From the classical Cayley-Hamilton theorem we have If (12)
(5) then and
is the Mittage-Leffler matrix function, (13) is the gamma function.
Proof. Using the Laplace transform ( taking into account that
) to (2a) and
Example 1. Find the solution of equation (2a) for and (14)
(6) Using (4) and (5) we obtain we obtain (15a) (7) where It is easy to check that
(15b) since (8)
since Substitution of (15) and
into(3) yields
(9) Substitution of (8) into (7) yields (10) Using the inverse Laplace transformation ( and the convolution theorem we obtain
(16)
) to (10)
(11) since
3. Positivity of continuous-time fractional systems
where
Definition 1. The fractional system (2) is called the internally positive fractional system if and only if and for for any initial conditions and all inputs .
¢ Note that the solution (3) of (2a) for and is the same as in [28] but the second term of (3) is different. Remark 1. From (4) and (5) for
we have
A square real matrix is called the Metzler matrix if its off-diagonal entries are nonnegative, i.e for [1, 5]. Lemma 1. Let
and
. Then (17)
and (18)
4
Regular papers
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
if and only if A is a Metzler matrix.
N° 1
2009
define the impulse response matrix of the system (2). The impulse response matrix of the system (2) is given by
Proof. Necessity. From the expansion
(22) Substitution of (3) into (2b) for
yields (23)
it follows that and only if A is a Metzler matrix.
for small
The formula (22) follows from (23) for
Theorem 3. The continuous-time fractional system (2) is externally positive if and only if its impulse response matrix (22) is nonnegative, i.e.
Sufficiency. It is well-known [5] that (19) if and only if A is a Metzler matrix. Using (17) we may write
(24) Proof. The necessity of the condition (24) follows immediately from Definition 2. The output of the system (2) with zero initial conditions for any input is given by the formula
(20)
since for . Thus from (20) and (19) we have The proof for (18) is similar.
.
.
¢ Theorem 2. The continuous-time fractional system (2) is internally positive if and only if the matrix A is a Metzler matrix and (21) Proof. Sufficiency. By Theorem 1 the solution of the equation (2a) has the form (3) and if (18) holds and A is a Metzler matrix since and for .
(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 A is a Metzler matrix and (21) holds then the impulse response matrix (22) is nonnegative. Therefore, we have the following two corollaries. Corollary 1. The impulse response matrix (22) of the internally positive system (2) is nonnegative. Corollary 2. Every continuous-time fractional internally positive system (2) is also externally positive.
4. Reachability and (the ith Necessity. Let column of the identity matrix ). The trajectory of the system does not leave the orthant only if what implies for . The matrix A has to be a Metzler matrix. For the same reason, for we have what implies since may be arbitrary. From (2b) for we have and and , since may be arbitrary. In a similar way, assuming we obtain and since may be arbitrary. ¢ Definition 2. The fractional system (2) is called externally positive if and only if for every input and .
of the fractional sysDefinition 3. The state tem (2) is called reachable in time if there exist an input which steers the state of system (2) from zero initial state to the state . If every stat is reachable in time the system is called reachable in time . If for every state there exist a time such that the state is reachable in time then the system (2) is called reachable.
The impulse response of single-input single-output system is called its output for the input equal to the Dirac impulse with zero initial conditions. Assuming successively that only one input is equal to and the remaining inputs and initial conditions are zero we may
(26)
A real square matrix is called monomial if and only if each its row and column contains only one positive entry and the remaining entries are zero. Theorem 4. The continuous-time fractional system (2) is reachable in time if the matrix
is a monomial matrix. The input which steers the state of the system (2) from to is given by the formula Regular papers
5
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
(27)
N° 1
2009
Remark 3. It is well-known that the system
where T denotes the transpose.
(32)
Proof. If the matrix (26) is a monomial matrix then and the input defined by (27) is an nonnegative vector, i.e. Using (3) for , (27) and (26) we obtain
with
(33)
Therefore, the input (27) steers the state of the system (2) from to . ¢
is reachable for any values of the coefficients since the reachability matrix (34)
and Theorem 5. If is a monomial matrix then the continuoustime fractional system (2) is reachable. Proof. From (5) it follows that if the matrix A is diagonal then the matrix is also diagonal and the matrix is monomial since the matrix B by assumption is monomial. From (26) written in the form
The system (32) is also reachable as a positive system if . The fractional system (2) with (33) even for is reachable if and only if there exist such that the following condition is met
(28) it follows that the matrix (28) is monomial. Thus by Theorem 3 the fractional system is reachable. ¢ Example 2. We shall show that the fractional system (2) with (29) is reachable. Taking into account that
(35)
The condition (35) follows from (3) for and that for , and
, (34) for
This example shows that the reachability conditions for the positive system (2) are much stronger than the conditions for positive system (32).
and using (5) we obtain (30)
5. Concluding remarks where
and
In this case from (28) we have (31)
The matrix (31) is monomial and by Theorem 3 the fractional system is reachable.
6
Regular papers
A new class of fractional positive continuous-time systems has been introduced. The solution to the state equation describing the fractional systems has been derived using the Laplace transform (Theorem 1). The classical Cayley-Hamilton theorem has been extended for the fractional systems (Remark 2). Necessary and sufficient conditions have been established for the internal and external positivity of the fractional systems (Theorem 2 and 3). Sufficient conditions for the fractional positive systems are much stronger than for classical positive systems. The considerations have been illustrated by examples of fractional continuous-time linear systems. The considerations presented for the reachability can be extended for controllability of the fractional continuous-time systems.
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
ACKNOWLEDGMENTS This work was supported by Ministry of Science and Higher Education in Poland under work No N514 1939 33.
AUTHOR Tadeusz Kaczorek - Professor at Białystok Technical University, Faculty of Electrical Engineering, Wiejska 45D, 15-351 Białystok, Poland. E-mail: kaczorek@isep.pw.edu.pl.
[18] [19] [20] [21]
[22]
References [1]
[2] [3]
[4]
[5] [6]
[7]
[8]
[9] [10]
[11]
[12] [13] [14]
[15]
[16]
[17]
N. Engheta, “On the role of fractional calculus in electromagnetic theory”, IEEE Trans. Atenn. Prop., vol. 39, no. 4, 1997, pp. 35-46. L. Farina and S. Rinaldi, Positive Linear Systems; Theory and Applications, J. Wiley, New York, 2000. N.M.F. Ferreira and J.A.T. Machado, “Fractional-order hybrid control of robotic manipulators”. In: Proc. 11th Int. Conf. Advanced Robotics, ICAR'2003, Coimbra, Portugal, pp. 393-398. K. Gałkowski, A. Kummer, “Fractional polynomials and nD systems”. In: Proc IEEE Int. Symp. Circuits and Systems, ISCAS'2005, Kobe, Japan, CD-ROM. T. Kaczorek, Positive 1D and 2D Systems, SpringerVerlag: London, 2002. T. Kaczorek, “Computation of realizations of discretetime cone systems”, Bull. Pol. Acad. Sci. Techn., vol. 54, no. 3, 2006, pp. 347-350. T. Kaczorek, Reachability and controllability to zero tests for standard and positive fractional discrete-time systems. T. Kaczorek, “Reachability and controllability to zero of positive fractional discrete-time systems”, Machine Intelligence and Robotic Control, vol. 6, no. 4, 2007. T. Kaczorek, “Reachability and controllability to zero of cone fractional linear systems” (in press). K. S. Miller and B. Ross, An Introduction to the Fractional Calculus and Fractional Differenctial Equations, Willey: New York, 1993. M. Moshrefi-Torbati and K. Hammond, Physical and geometrical interpretation of fractional operator., J. Franklin Inst., vol. 335B, no. 6, 1998, pp. 1077-1086. K. Nishimoto, Fractional Calculus, Decartess Press: Koriama, 1984. K. B. Oldham and J. Spanier, The Fractional Calculus, Academic Press: New York, 1974. M. D. Ortigueira, “Fractional discrete-time linear systems”. In: Proc. of the IEE-ICASSP 97, Munich, Germany, IEEE, New York, vol. 3, pp. 2241-2244. P. Ostalczyk, “The non-integer difference of the discrete-time function and its application to the control system synthesis”, Int. J. Syst, Sci., vol. 31, no. 12, 2000, pp. 1551-1561. P. Ostalczyk, “Fractional-Order Backward Difference Equivalent Forms Part I Horner's Form”. In: Proc. 1st IFAC Workshop Fractional Differentiation and its Applications, FDA'04, Enseirb, Bordeaux, France, 2004, pp. 342-347. P. Ostalczyk, “Fractional-Order Backward Difference Equivalent Forms Part II Polynomial Form”. In: Proc. 1st IFAC Workshop Fractional Differentiation and its
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
N° 1
2009
Applications, FDA'04, Enseirb, Bordeaux, France, 2004, pp. 348-353. A. Oustalup, Commande CRONE, Hermés: Paris, 1993. A. Oustalup, La dérivation non entiére, Hermés: Paris, 1995. I. Podlubny, Fractional Differential Equations, Academic Press: San Diego, 1999. I. Podlubny, “Geometric and physical interpretation of fractional integration and fractional differentiation”, Fract. Calc. Appl. Anal., vol. 5, no. 4, 2002, pp. 367-386. I. Podlubny, L. Dorcak and I. Kostial, “On fractional derivatives, fractional order systems and PIlDμ-controllers”. In: Proc. 36th IEEE Conf. Decision and Control, San Diego, CA, 1997, pp. 4985-4990. M.E. Reyes-Melo, J.J. Martinez-Vega, C.A. GuerreroSalazar and U. Ortiz-Mendez, “Modelling and relaxation phenomena in organic dielectric materials. Application of differential and integral operators of fractional order”, J. Optoel. Adv. Mat., vol. 6, no. 3, 2004, pp. 1037-1043. D. Riu, N. Retiére and M. Ivanes, “Turbine generator modeling by non-integer order systems”. In: Proc. IEEE Int. Electric Machines and Drives Conference, IEMDC 2001, Cambridge, MA, 2001, pp. 185-187. S. G. Samko, A.A. Kilbas and O.I. Martichew, Fractional Integrals and derivative. Theory and Applications. Academic Press: London, 1993. D. Sierociuk and D. Dzieliński, “Fractional Kalman filter algorithm for the states, parameters and order of fractional system estimation”, Int. J. Appl. Math. Comp. Sci., vol. 16, no. 1, 2006, pp. 129-140. M. Sjöberg and L. Kari, “Non-linear behavior of a rubber isolator system using fractional derivatives”, Vehicle Syst. Dynam., vol. 37, no. 3, 2002, pp. 217-236. B. M. Vinagre, C. A. Monje and A.J. Calderon, Fractional order systems and fractional order control actions. Lecture 3 IEEE CDC'02 TW#2: Fractional calculus Applications in Autiomatic Control and Robotics. B. M. Vinagre and V. Feliu, “Modeling and control of dynamic system using fractional calculus: Application to electrochemical processes and flexible structures”. In: Proc. 41st IEEE Conf. Decision and Control, Las Vegas, NV, 2002, pp. 214-239. V. Zaborowsky and R. Meylaov, “Informational network traffic model based on fractional calculus”. In: Proc. Int. Conf. Info-tech and Info-net, ICII 2001, Beijing, China, vol. 1, pp. 58-63.
Regular papers
7
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
POINTWISE COMPLETENESS AND POINTWISE DEGENERACY OF LINEAR CONTINUOUS-TIME FRACTIONAL ORDER SYSTEMS Received 3rd September 2008; accepted 14th November 2008.
Tadeusz Kaczorek, Mikołaj Busłowicz
Abstract: A dynamical system described by homogeneous equation is called pointwise complete if every final state can be reached by suitable choice of the initial state. The system, which is not pointwise complete, is called pointwise degenerated. Definitions and necessary and sufficient conditions for the pointwise completeness and the pointwise degeneracy of continuous-time linear systems of fractional order, standard and positive, are given. It is shown that: 1) the standard fractional system is always pointwise complete; 2) the positive fractional system is pointwise complete if and only if the state matrix is diagonal.
systems standard and positive will be given. To the best knowledge of the authors the pointwise completeness and pointwise degeneracy of fractional order systems have not been considered yet. 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 results 2.1. Standard systems Consider the fractional continuous-time linear system described by the homogeneous equation
Keywords: inear system, fractional, continuous-time, positive, pointwise completeness.
(1) where
1. Introduction A dynamical system without input signal is called pointwise complete if every final state can be reached by suitable choice of the initial state. The system, which is not pointwise complete, is called pointwise degenerated. The problem of pointwise completeness and pointwise degeneracy of linear continuous-time systems with delays has been considered in [5, 14, 16, 18]. The problem of pointwise completeness and pointwise degeneracy of linear discrete-time systems with delays has been formulated and solved in [1, 2] for the standard systems and in [4] for the positive systems. In positive systems inputs, state variables and outputs take only non-negative values. Examples of positive systems are industrial processes involving chemical reactors, heat exchangers and distillation columns, storage systems, compartmental systems, water and atmospheric pollution models. A variety of models having positive linear systems behaviour can be found in engineering, management science, economics, social sciences, biology and medicine, etc. An overview of state of the art in positive systems is given in the monographs [7, 10]. In the last decades, the problem of analysis and synthesis of dynamical systems described by fractional order differential (or difference) equations was considered in many papers and books (see [6, 15, 17], for example). The new class of linear systems of fractional order, namely the positive fractional systems, has been introduced in [11-13]. In this paper we consider the problem of pointwise completeness and pointwise degeneracy of linear continuous-time systems of fractional order. Definitions and necessary and sufficient conditions for the pointwise completeness and the pointwise degeneracy of fractional 8
Regular papers
is the order of fractional derivative, and . The following Caputo definition of the fractional a-order derivative will be used [12] (2)
where
is the Euler gamma function and
p is an integer satisfying the inequality . It is easy to see that for we have p=1 and (2a) The solution of equation (1) with by [12]
is given
(3) where (4) is the fundamental matrix and Leffler matrix function. The fundamental matrix and the matrix A.
is the Mittagedepends on the time t
Lemma 1. The fundamental matrix (4) is always nonsingular, i.e. (5) for all
and for any matrix
.
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
Proof. 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 A. Let be real or complex eigenvalues (not necessarily distinct) of A. Then from (6) it follows that for any real and for any complex conjugate pair It is well known [8, 9] that the eigenvalues of the matrix are: and (7) ¢ The fundamental matrix (4) can be computed by using the Sylvester formula [8, 9]. In the case of distinct eigenvalues of A we have the following lemma.
N° 1
2009
By generalisation of definitions of pointwise completeness and pointwise degeneracy to the case of fractional order systems (1) one obtains the following definitions. Definition 1. The fractional system (1) is called pointwise complete at if for every final vector there exists an initial state such that . Definition 2. The fractional system (1) is called pointwise degenerated in the direction v at if there exists a non-zero vector such that for all initial states the solution of (1) for satisfies the condition , where T denotes the transpose. From the above definitions and Lemma 1 we have the following important theorem. Theorem 1. The fractional continuous-time system (1) is always pointwise complete, i.e. for any finite state there exists the initial state
Lemma 2. If A has only distinct eigenvalues then the fundamental matrix (4) can be computed from the formula
(15) such that
(8)
Example 1. Using the Sylvester formula check the fundamental 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
for Proof. From Lemma 1 we have that any matrix and for all Hence, from (3) it follows that for any given finite state we can always compute the initial state from the formula (15). ¢ Example 2. Consider the system (1) with (16) It is easy to see that (16) is a nilpotent matrix with the nilpotency index i.e. for
(10) From Lemma 3 for
we have
where (11) ¢ From (4) it follows that the fundamental matrix can be written in the form (12) where
(17)
where
is defined by (13) for
.
From Theorem 1 it follows that the fractional system is pointwise complete and for any final state we can find the suitable initial state from the formula
(13) (18) From (12) we have the following lemma. Lemma 3. If A is a nilpotent matrix with the nilpotency index μ (i.e. for and ) then
If, for example,
and
then (19)
(14) Regular papers
9
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
2.2. Positive systems Definition 3. The fractional system (1) is called positive if and only if for any . A square real matrix is called the Metzler matrix if its off-diagonal entries are non-negative, i.e. for . In the paper [12] the following theorem has been proved. Theorem 2. The fractional system (1) is positive if and only if the matrix A is a Metzler matrix. Definitions of pointwise completeness and pointwise degeneracy of positive fractional system (1) can be formulated as follows. Definition 4. The positive fractional system (1) is called pointwise complete at if for every vector there exists an initial state such that . Definition 5. The positive fractional system (1) is called pointwise degenerated if it is not pointwise complete, that is there exists at least one state which can not be reached from any initial state i.e. does not exist and such that . Theorem 3. The positive fractional system (1) is pointwise complete at if and only if the matrix A is diagonal. Proof. In positive systems, according to Definition 3, and . From (15) it follows that for any there exists if and only if . It is well known [10] that if and only if is a monomial matrix (in each row and in each column only one entry is positive and remaining entries are zero). From (12) it follows that is a monomial matrix if and only if the matrix A is diagonal. ¢
If
then from (15) we have
The paper considers the problem of pointwise completeness and pointwise degeneracy of linear continuoustime systems of fractional order, described by the homogeneous equation (1). First, the definitions of the pointwise completeness and pointwise degeneracy of the standard (i.e. non-positive) fractional systems have been introduced (Definitions 1 and 2) and it has been proved that the fractional continuous-time system (1) is always pointwise complete (Theorem 1). Next, the definitions (Definitions 4 and 5) and necessary and sufficient conditions of the pointwise completeness (Theorem 3) and pointwise degeneracy (Theorem 4) of the positive fractional systems have been given. It has been shown that the positive system (1) is pointwise complete if and only if the state matrix A is diagonal. The considerations can be extended for the fractional discrete-time systems [3].
AUTHORS Tadeusz Kaczorek and Mikołaj Busłowicz* - Białystok Technical University, Faculty of Electrical Engineering, ul. Wiejska 45D, 15-351 Białystok, Poland, E-mails: kaczorek@isep.pw.edu.pl, busmiko@pb.edu.pl. * Corresponding author
References [1]
[2]
Theorem 4. The positive fractional system (1) is pointwise degenerated if and only if A is not a diagonal matrix.
[3]
Example 3. In Example 2 it was shown that the standard system (1) with the Metzler matrix (16) is pointwise 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 pointwise degenerated. This result also follows from Theorem 3.
[4]
Example 4. Consider the positive system (1) with the matrix (9). Fundamental matrix of the system has the form (10). By Theorem 3 the positive fractional system is pointwise complete at any since the matrix (10) is diagonal. Using (15) we may find for any given .
[6]
Regular papers
2009
3. Concluding remarks
From Definition 5 and Theorem 3 we have the following theorem.
10
N° 1
[5]
[7] [8] [9]
Busłowicz M., "Controllability of linear discrete-delay systems". In: Proc. Intern. Conf. Functional Differential Systems and Related Topics, Błażejewko, Poland, 1981, pp. 47-51. Busłowicz M., "On some properties of solution of state equation of discrete-time systems with delays", Zesz. Nauk. Polit. Biał., Elektrotechnika, vol. 1, 1983, pp. 17-29 (in Polish). Busłowicz M., "Pointwise completeness and pointwise degeneracy of linear discrete-time systems of fractional order", Zesz. Nauk. Pol. Śląskiej, Automatyka, no. 151, 2008, pp. 19-24 (in Polish). Busłowicz M., Kociszewski R., Trzasko W., "Pointwise completeness and pointwise degeneracy of positive discretetime systems with delays", Zesz. Nauk. Pol. Śląskiej, Automatyka, no. 145, 2006, pp. 51-56 (in Polish). Choundhury A. K., "Necessary and sufficient conditions of pointwise completeness of linear time-invariant delay-differential systems", Int. J. Control, vol. 16 (6), 1972, pp. 1083-1100. Das. S, Functional Fractional Calculus for System Identification and Controls, Springer, Berlin 2008. Farina L. and Rinaldi S., Positive Linear Systems; Theory and Applications, J. Wiley: New York, 2000. Gantmacher F. R., Theory of Matrices, vol. I and II, Chelsea: New York, 1960. Kaczorek T., Vectors and Matrices in Automatics and
Journal of Automation, Mobile Robotics & Intelligent Systems
[10] [11]
[12]
[13]
[14]
[15] [16]
[17]
[18]
VOLUME 3,
N° 1
2009
Electrotechnics, WNT, Warszawa 1998 (in Polish). Kaczorek T., Positive 1D and 2D Systems, Springer, London 2002. Kaczorek T., "Reachability and controllability to zero of positive fractional discrete-time systems", Machine Intelligence and Robotics Control, vol. 6, no.4, 2008, pp. 139-143. Kaczorek T., “Fractional positive continuous-time linear systems and their reachability”, Int. J. Appl. Math. Comput. Sci., vol. 18, no. 2, 2008, pp. 223-228. Kaczorek T., "Reachability and controllability to zero tests for standard and positive fractional discrete-time systems", Journal of Automation and System Engineering, vol. 42, no. 6-7-8, 2008, pp. 769-787. Olbrot A., "On degeneracy and related problems for linear constant time-lag systems". Ricerche di Automatica, vol. 3, no. 3, 1972, pp. 203-220. Podlubny I., Fractional Differential Equations, Academic Press, San Diego 1999. Popov V. M., "Pointwise degeneracy of linear timeinvariant delay-differential equations", Journal of Diff. Equations, issue 11, 1972, pp. 541-561. Sabatier J., Agrawal O. P. and Machado J. A. T. (Eds), Advances in Fractional Calculus, Theoretical Developments and Applications in Physics and Engineering, Springer London 2007. Weiss L., "Controllability for various linear and nonlinear systems models", Lecture Notes in Mathematics, vol. 144, Seminar on Differential Equations and Dynamic System II, Springer, Berlin 1970, pp. 250-262.
Regular papers
11
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
STABILITY ANALYSIS OF LINEAR CONTINUOUS-TIME FRACTIONAL SYSTEMS OF COMMENSURATE ORDER Received 27th May 2008; accepted 13th August 2008.
Mikołaj Busłowicz
Abstract: The paper considers the stability problem of linear timeinvariant continuous-time systems of fractional commensurate order. It is shown that the system is stable if and only if plot of rational function of fractional order (called the generalised modified Mikhailov plot) does not encircle the origin of the complex plane. The considerations are illustrated by numerical examples. Keywords: stability, linear system, continuous-time, fractional, commensurate order.
and p is an integer satisfying inequality . Applying the Laplace transform to both sides of equation (1) and assuming zero initial conditions, we obtain the following fractional order transfer function (3) The fractional order linear system with the transfer function (3) is of [23]: commensurate order if (4)
1. Introduction In the last decades, the problem of analysis and synthesis of dynamical systems described by fractional order differential (or difference) equations was considered in many papers, see [4, 9, 10, 12, 18, 21, 23], for example. Some applications of fractional order systems can be found in [5, 19, 20-22]. The stability problem of linear continuous-time systems of fractional order has been studied in [2, 3, 6, 7, 8, 23]. The new class of the linear fractional order systems, namely the positive systems of fractional order has been considered in [15-17]. The aim of this paper is to give the new frequency domain methods for stability analysis of linear continuoustime fractional systems in the case of commensurate degree characteristic polynomials. To the best knowledge of the Author, computationally effective frequency domain methods for stability analysis of fractional commensurate degree polynomials have not been proposed yet.
where a > 0 is a real number, rational order if it is a commensurate order and a = 1 / q where q is a positive integer, non-commensurate order if (4) does not hold. The transfer function of fractional system of commensurate order can be written in the form (5) Substituting in (5), one obtains the associated natural order transfer function (6) If, for example, (7a) then for one obtains the associated natural order transfer function
2. Preliminaries and problem formulation A linear single input, single output continuous-time dynamical system of fractional order is described by the following fractional differential equation (see [23] for example)
Characteristic polynomial of the fractional system (1) has the form
(1)
(8)
where u(t) is the input, y(t) is the output, and bitrary real numbers, and are real coefficients and
are ar-
(2)
(7b)
The polynomial (8) is a multivalued function whose domain is a Riemann surface. In general, this surface has an infinite number of sheets and the fractional polynomial (8) has an infinite number of zeros. Only a finite number of which will be in the main sheet of the Riemann surface. For stability reasons only the main sheet defined by can be considered [23].
is the Caputo definition for fractional a-order derivative where 12
Regular papers
is the Euler gamma function
Theorem 1 [7, 8, 23]. The fractional order system with the transfer function (3) is bounded-input bounded-
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
output (BIBO) stable (shortly stable) if and only if the fractional degree characteristic polynomial (8) is stable, i.e. this polynomial has no zeros in the closed right half of the Riemann complex surface, that is (9) The Riemann surface has a finite number of sheets only in the case of fractional polynomials (8) of commensurate degree, i.e. for (10) If (10) holds, the fractional degree characteristic polynomial (8) can be written in the form (11) Hence, for from (11) we obtain the associated natural number degree polynomial
N° 1
2009
degree polynomial and from (14) we have that the imaginary axis of the complex plane is the boundary of the stability region. From the above and Theorem 2 we have the following sufficient condition for stability of fractional degree polynomial (11) with . Lemma 1. The fractional commensurate degree characteristic polynomial (11) with is stable if the associated natural number degree polynomial (12) is asymptotically stable, i.e. the condition (13) holds for for all zeros a = 1, which means that of (12). From Theorem 2 it follows that the fractional polynomial (11) may be stable in the case when the associated natural degree polynomial (12) is not asymptotically stable. Stability checking of the fractional degree polynomial (11) on the basis of Theorem 2 is a difficult problem in general, because the degree of the associated polynomial (12) may be very large. If, for example,
(12) If, for example, (a and b are real numbers) then , and the associated natural number degree polynomial has the form
Theorem 2 [23]. The fractional commensurate degree characteristic polynomial (11) is stable if and only if all zeros of this polynomial satisfy the condition (9) or, equivalently, all zeros of the associated natural degree polynomial (12) satisfy the condition (13) If then from (13) we obtain the stability region shown in Figure 1.
then for one obtains the associated polynomial of natural degree [6]
The above polynomial has degree equal to 127 and only five non-zero coefficients. To avoid this difficulty, a method for determination of the multi-variate natural degree polynomial, associated with the fractional commensurate degree polynomial has been given in [6]. To stability analysis of multi-variate degree polynomials, the LMI technique has been proposed in [6]. The aim of this paper is to give the new frequency domain methods for stability analysis of fractional polynomials of commensurate degree. The methods proposed are based on the Mikhailov stability criterion and the modified Mikhailov stability criterion, known from the theory of systems of natural number order (see [1, 14, 24], for example).
3. Solution of the problem
Fig. 1. Stability region of fractional degree polynomial (11) in the complex -plane with . Parametric description of the boundary of the stability region has the form (14) The polynomial (11) with a = 1 is a natural number
In the stability theory of natural degree characteristic polynomials of linear continuous-time systems, the following kinds of stability are considered (see [1], for example): — asymptotic stability (all zeros of the characteristic polynomial have negative real parts), — D-stability (all zeros of the characteristic polynomial lie in the open region D in the left half-plane of complex plane). From the above and Theorem 2 we have the following lemma. Lemma 2. The fractional degree polynomial (11) is stable if and only if the associated natural degree polynomial (12) is D-stable, where the parametric description the boundary of the region D has the form (14). In partiRegular papers
13
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
cular, for the D-stability region is shown in Figure 1. It is easy to see that if a = 1 then the fractional degree polynomial (11) is reduced to the natural degree polynomial (12) with . In such a case from (14) it follows that boundary of the stability region is the imaginary axis of the complex plane.
N° 1
2009
which holds if and only if (18) is satisfied. ¢ The reference fractional polynomial can be chosen in the form (21)
Theorem 3. The fractional degree characteristic polynomial (11) is stable if and only if (15) where
for
Proof. It is easy to see that This means that (15) is the necessary and sufficient condition for D-stability of the natural degree polynomial (12) [1]. Hence, the proof follows from Lemma 2. ¢ Plot of the function where for will be called the generalised (to the class of fractional degree polynomials) Mikhailov plot. Satisfaction of (15) means that the generalised Mikhailov plot starts for in the point on real axis and with increasing from 0 to turns strictly counter-clockwise and goes through n quadrants of the complex plane. Checking the condition (15) of Theorem 3 is difficult in general (for large values of n), because quickly tends to infinity as grows to . To remove this difficulty, we consider the rational function
Note that for c > 0 the reference polynomial (21) is stable. Plot of the function is defined by (16)) we will called the generalised modified Mikhailov plot. The condition (18) of Theorem 4 holds if and only if the generalised modified Mikhailov plot does not encircle the origin of the complex plane as runs from to . From (11), (16) and (21) we have (22) and (23) From (23) it follows that if Hence, from Theorem 4 we have the following important lemma. Lemma 3. The fractional degree polynomial (11) is not stable if . Now we consider the case in which the condition (18) of Theorem 4 does not hold.
(16) instead of the polynomial (11), where is the reference fractional polynomial of the same degree as polynomial (11). We will assume that the reference fractional polynomial is stable, i.e.
Theorem 5. The fractional characteristic polynomial (11) of commensurate degree has k ³ 0 zeros in the right half of the Riemann complex surface if and only if as runs from to the plot of times encirclese in the negative direction the origin of the complex plane. In such a case
(17)
(24)
Theorem 4. The fractional degree polynomial (11) is stable if and only if
Proof. As in [14] in the case of natural degree polynomials we can show that if the fractional degree polynomial (11) has k ³ 0 zeros with positive real parts, then
for
(18) (25) where (16).
for
and
Proof. If the reference polynomial then from Theorem 3 we have
is defined by
is stable
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 Theorem 5 for k = 0.
(19)
4. Illustrative examples From (16) for
it follows that (20)
The fractional degree polynomial (11) is stable if and only if 14
Regular papers
Example 1. Consider a linear fractional order system with characteristic polynomial of commensurate degree of the form [6]
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
In this case, the generalised modified Mikhailov plot with the reference polynomial is shown in Figure 3, where
(26) Zeros of natural degree polynomial (27) with negative free term and the boundary of the stability region are shown in Figure 4.
For and from the fractional commensurate degree polynomial (26) we obtain the associated natural degree polynomial
(27)
Fig. 3. Plot of the function (16) with D(s) of the form (26) with negative free term. From Theorem 2 it follows that the fractional degree polynomial (26) is stable if and only if the associated natural degree polynomial (27) has no zeros in the cone shown in Figure 1 with . Plot of the function (16) with is shown in Figure 2. According to (22) and (23) we have
Fig. 4. Zeros of polynomial (27) with negative free term and boundary of the stability region. From Figure 3 it follows that the generalised modified Mikhailov plot ones encircles the origin of the complex plane in negative direction. This means, according to Theorem 5, that the system is unstable and the characteristic polynomial has one unstable zero. This zeros lies in the instability region shown in Figure 4.
Fig. 2. Plot of the function (16) with
.
From Figure 2 it follows that the generalised modified Mikhailov plot does not encircle the origin of the complex plane and the system is stable, according to Theorem 4. Now we consider the fractional degree polynomial (26) and associated natural degree polynomial (27) in the case when the free term has negative sign, i.e. is -221.9590294 instead of +221.9590294. In such a case and the fractional system is not stable, according to Lemma 3.
Example 2. Consider the control system with the fractional 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 system with the plant (28) and controller (29) has the form Regular papers
15
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
(30) Substituting and in (30), one obtains the associated polynomial of natural degree
N° 1
2009
the fractional characteristic polynomial (11) has k ³ 0 zeros in the right half of the Riemann complex surface if and only if as w runs from to the generalised modified Mikhailov plot times encircles in the negative direction the origin of the complex plane (Theorem 5).
(31) The control system is stable if and only if all zeros of polynomial (31) lie in the stability region shown in Figure 1 with . To stability checking of fractional polynomial (30) we apply Theorem 4. Plot of the function where is the D(s) has the form (30) and reference fractional polynomial, is shown in Figure 5.
The effectiveness of the methods has been illustrated by numerical examples. Generalisation of the main result of the paper (Theorem 4) for the fractional systems of non-commensurate order has been given in [2]. The preliminary version of this paper was presented at the conference Automation'2008 which was held in Warsaw, Poland and published in [3]. The considerations can be generalised to the linear fractional order systems with delays. ACKNOWLEDGMENTS The work was supported by the Ministry of Science and High Education of Poland under grant No. N N514 1939 33.
AUTHOR Mikołaj Busłowicz - Professor at Białystok Technical University, Faculty of Electrical Engineering, ul. Wiejska 45D, 15-351 Białystok, Poland. E-mail: busmiko@pb.edu.pl.
Fig. 5. Plot of the function
.
References [1]
From (22) and (23) we have
[2]
From Figure 5 it follows that the generalised modified Mikhailov plot does not encircle the origin of the complex plane. This means that the fractional control system is stable, according to Theorem 4.
5. Concluding remarks New frequency domain methods for stability analysis of linear systems of fractional commensurate order have been given. The methods have been obtained by generalisation of the Mikhailov stability criterion and the modified Mikhailov stability criterion (known from the theory of natural order systems) to the case of fractional order systems. In particular it has been shown that: the fractional polynomial (11) is stable if and only if plot of D(jw) with w increasing from 0 to turns strictly counter-clockwise and goes through n quadrants of the complex plane (Theorem 3), the fractional polynomial (11) is stable if and only if plot of the rational function y(jw), where y(s) is defined by (16), called the generalised modified Mikhailov plot, does not encircle the origin of the complex plane (Theorem 4), 16
Regular papers
[3]
[4] [5]
[6]
[7]
[8]
[9]
Busłowicz M., Stability of linear time-invariant systems with uncertain parameters, Publishing Department of Technical University of Białystok, Białystok 1997 (in Polish). Busłowicz M., "Frequency domain method for stability analysis of linear continuous-time fractional systems". In: K. Malinowski, L. Rutkowski (Eds.): Recent Advances in Control and Automation, Academic Publishing House EXIT: Warsaw 2008, pp. 83-92. Busłowicz M., "Stability of linear continuous-time fractional systems of commensurate order", Pomiary Automatyka Robotyka, no. 2, 2008, 475-484 (on CD-ROM) (in Polish). Das. S, Functional Fractional Calculus for System Identification and Controls, Springer, Berlin 2008. Ferreira N. M. F., Machado J. A. T., "Fractional-order hybrid control of robotic manipulators". In: Proc. of 11th Int. Conf. Advanced Robotics, ICAR'2003, Coimbra 2003, Portugal, 393-398. Gałkowski K., Bachelier O., Kummert A., "Fractional polynomial and nD systems a continuous case. In: Proc. of IEEE Conference on Decision & Control, San Diego 2006, USA. Matignon D., "Stability results on fractional differential equation with applications to control processing". In: Proc. of IMACS, Lille 1996, France. Matignon D., "Stability properties for generalized fractional differential systems". In: Proc. of ESAIM, 1998, pp. 145-158. Ortigueira M. D., "Introduction to fractional linear systems. Part 1: Continuous-time case". In: IEE Proc. – Vis.
Journal of Automation, Mobile Robotics & Intelligent Systems
[10]
[11]
[12] [13]
[14] [15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
VOLUME 3,
N° 1
2009
Image Signal Process, no. 147, 2000, pp. 62-70. Ortigueira M. D., "Introduction to fractional linear systems. Part 2: Discrete-time systems". In: IEE Proc. – Vis. Image Signal Process, no. 147, 2000, pp. 71-78. Podlubny I., Fractional order systems and fractional order controllers. The Academy of Sciences Institute of Experimental Physis, Kosice, Slovak Republic, 1994. Podlubny I., Fractional Differential Equations, Academic Press, San Diego 1999. Sierociuk D., Estimation and control of discrete dynamical systems of fractional order in state space, PhD Dissertation, Faculty of Electrical Engineering, Warsaw University of Technology, Warsaw 2007 (in Polish). Kaczorek T., Theory of Control Systems, WNT: Warszawa, 1974 (in Polish). Kaczorek T., "Reachability and controllability to zero of positive fractional discrete-time systems", Machine Intelligence and Robotics Control, vol. 6, no. 4, 2008, pp. 139-143. Kaczorek T. "Reachability of fractional positive continuous-time linear systems", Pomiary Automatyka Robotyka, no. 2, 2008, pp. 527-537 (on CD-ROM). Kaczorek T, “Fractional positive continuous-time linear systems and their reachability”, Int. J. Appl. Math. Comput. Sci., vol. 18, no. 2, 2008, pp. 223-228. Kilbas A. A., Srivastava H. M. Trujillo J. J., Theory and Applications of Fractional Differential Equations, Elsevier, Amsterdam 2006. Reyes-Melo E., Martinez-Vega J.J., Guerrero-Salazar C.A., Ortiz-Mendez U., "Modelling and relaxation phenomena in organic dielectric materials. Application of differential and integral operators of fractional order". J. Optoel. Adv. Mat., vol. 6, no , 2004, pp. 1037-1043. Riu D., Retiére N., Ivanes M., "Turbine generator modeling by non-integer order systems". In: Proc. IEEE Int. Electric Machines and Drives Conference, IEMDC 2001, England, Cambridge, 2001, pp. 185-187. Sabatier J., Agrawal O. P., Machado J. A. T. (Eds), Advances in Fractional Calculus, Theoretical Developments and Applications in Physics and Engineering, Springer, London 2007. Sjöberg M., Kari L., "Non-linear behavior of a rubber isolator system using fractional derivatives". Vehicle Syst. Dynam., vol. 37, no. 3, 2002, pp. 217-236. Vinagre B. M., Monje C. A., Calderon A. J., "Fractional order systems and fractional order control actions", Lecture 3. In: Proc. of IEEE CDC'02 TW#2: Fractional Calculus Applications in Automatic Control and Robotics, Las Vegas 2002. Wright W. C., Kerlin T. W., "An efficient computer oriented method for stability analysis of large multivariable systems", Trans. ASME Journal Basic Eng., no. 92, 1970, pp. 279-286. Zhao Ch., Xue D., Chen Y.-Q. (2005), "A fractional order PID tuning algorithm for a class of fractional order plants". In: Proc. IEEE Intern. Conf. on Mechatronics & Automation, Niagara Falls 2005, Canada, pp. 216-221.
Regular papers
17
Journal of Automation, Mobile Robotics & Intelligent Systems
VOLUME 3,
N째 1
2009
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
SPECIAL ISSUE SECTION
Dependability and Safety of Real-Time Computer Systems Editors: Wojciech Grega, Andrew J. Kornecki, Janusz Zalewski
2009
Journal of Automation, Mobile Robotics & Intelligent Systems
VOLUME 3,
N° 1
Editorial Special Issue on Dependability and Safety of Real-Time Computer Systems It is our great pleasure to present our readers with this special issue of JAMRIS on Dependability and Safety of Real-Time Computer Systems. The articles in this issue are extended and revised versions of papers nd that have been selected from submissions to the RTS'07, 2 Workshop on Real-Time Software, which took place as a part of the IMCSIT Conference (International Multi-conference on Computer Science and Inforth th mation Technology), organised by the Polish Information Processing Society (PTI), in Wisła, Poland, 15 -17 October 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 to be a few years ago, but also in everyday life. Digital, microprocessor-based devices are present in every aspect of our daily life, from door locks and alarm clocks, to cell phones, to cars, traffic lights, and medical equipment, banking terminals, airplanes and space probes. The common characteristic of all these computercontrolled devices and systems is that they depend on the proper operation of microprocessors that are embedded 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 pose significant problems related to software dependability and safety. Dependability 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 definition reflects the fact that the concept of dependability is a complex one, and has several aspects. One of these aspects involves dependability attributes, i.e., critical properties that constitute the notion of dependability. 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 “performing required functions under stated conditions for a specified period of time” (IEEE Glossary of Software Engineering 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 be described as freedom of risk, to a human or a society, caused by a computer or software. In this sense, safety is a property very different from reliability, which reflects only performing required functions without taking into account risks, and is a direct inversion of security, in a sense that security deals with protecting a computer system from external threats, while safety deals with protecting the external world from the consequences of a computer malfunction. Computer systems that require special consideration regarding safety, for example in applications such as flight control and traffic control, road vehicles, railway interchanges, nuclear facilities, medical equipment and implanted devices, etc., are called safety-critical systems. The question fundamental to the development of safety-critical computer systems is: How to achieve and improve dependability and safety? Taking into account the typical development cycle of such systems, composed in the simplest case of three general stages: requirements specification, design, and implementation, one can look at ways of addressing dependability and safety at each individual stage. This is, roughly speaking, how the papers in this 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 in this issue represent such research paradigm. Leuchter, Tyszberowicz and Feldman discuss a method and tool to translate specifications expressed in Verilog into an equivalent representation in a synchronous language
20
Editorial
2009
Journal of Automation, Mobile Robotics & Intelligent Systems
VOLUME 3,
N° 1
2009
Esterel. Their tool, Veriest, is a translator that converts respective designs. Since many libraries of useful designs, such as communication protocols, compression algorithms, are available in Verilog, the large body of 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 the Coq proof 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 for reachability analysis is presented, which allows avoiding spurious transactions for certain classes of hybrid systems. Kosęda, Szmuc and Cichalewski use a formal approach in designing automation software for the free electron laser. They present a method for formal specification and verification of software, based on model checking with NuSMV tool. The tool is used to verify formal properties included in the specification of software. A dedicated converter translates the model expressed in the specification language into the NuSMV's input language. Definitions of formal properties to be fulfilled by the model are expressed in Computational 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. Two papers addressing such approach are included in this issue, both based on developing more realistic architectural models, using the UML modelling language, specifically the statecharts, to express designs related to improving safety. Letia, Barbu and Dinga propose to increase software dependability directly addressing the safety issues in road traffic control, by developing a general pre-emptive scheduling algorithm. It is based on using local priorities to schedule critical resources and global priorities to impact global traffic patterns. The simulation results demonstrate that the proposed solution provides robust performance for relatively low traffic volumes. The second paper in this category, by Lu and Halang, deals with combining component-based software architecture models with established fault tolerance techniques. Fault tolerance is often used in research and practice as a method of improving dependability and safety. It is defined (IEEE Glossary of Software Engineering Terminology) as “the ability of a system or component to continue normal operation despite the presence of hardware or software faults”. As such, it encompasses special techniques to mitigate or avoid consequences of faults. The paper presents an architecture described in terms of normal- and abnormalactivity components aiming to support a wide variety of fault tolerance features, and suggest extending UML to 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 safety and 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 algorithms: Dynamic Matrix Control (DMC) and Generalized Predictive Control (GPC). Dependability of both algorithms is evaluated using a software-implemented fault injection technique. Tests performed on the control system of a remotely controlled robot vehicle show that the considered algorithms may exhibit unacceptable output response, such as slow or oscillatory behaviour, and require exception handling to address these and related problems. Piątek and Grega also analyse the behaviour of a digitally implemented controller for a magnetic levitation device, by studying its speed. Their concern is that the performance of a digital control system depends not only on variables, such as the sampling period, control loop execution time, jitter, and general performance of individual components, but also on their interaction and cooperation. They propose a new design approach based on the relative speed system classification that relies on balancing the closed-loop execution time and process dynamics. The detailed analysis and optimisation of control algorithm performance usually involves dealing with the implementation at the operating system level. This is the focus of the last, but not least, paper in this category. Moryc and Èernohorský present an analysis of realtime task jitter under RTLinux operating system. They describe methods and tools developed to measure jitter, and discuss the results obtained for a data acquisition system. They conclude that the Linux kernel itself significantly contributes to the real-time task jitter, and suggest that employing a CPU designed specifically for real-time operation could mitigate the effects. Discussion of dependability and safety of real-time computer systems would not be complete without touching one extremely important subject: education. Therefore, we have included a paper on curriculum development for real-time software-intensive control systems, by Kornecki et al. The authors report on the international activities, involving American, Polish, Czech and French universities, focused on designing and implementing a coordinated curriculum that would engage students from multilingual, geographically
Editorial
21
Journal of Automation, Mobile Robotics & Intelligent Systems
VOLUME 3,
N° 1
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 is that joint efforts will help in creation of international curricula with a compatible quality assurance and assessment 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-time computer systems, collected in a single issue, will be of interest to the readers of JAMRIS. Those interested in this subject more deeply may consider submitting papers to the next edition of the RTS Workshop, which is planned for the 2009 IMCSIT conference in Mrągowo, on 12-14 October 2009. For details, please see http://www.imcsit.org/ or contact the editors of this special issue.
Wojciech Grega AGH University of Science and Technology, Kraków, Poland wgr@ia.agh.edu.pl Andrew J. Kornecki Embry-Riddle Aeronautical University, Daytona Beach, Florida, USA kornecka@erau.edu Janusz Zalewski Florida Gulf Coast University, Fort Myers, Florida, USA zalewski@fgcu.edu
22
Editorial
2009
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
REUSING VERILOG DESIGNS IN THE SYNCHRONOUS LANGUAGE ESTEREL Menachem Leuchter, Shmuel Tyszberowicz, Yishai A. Feldman
Abstract: Verilog is one of the two most popular high-level hardware description languages. Many libraries of useful designs, such as communication protocols and compression algorithms, are available in Verilog. These designs could be useful to designers of real-time and reactive systems if they could be translated into the languages used for such designs. Synchronous languages are particularly useful for describing the control of real-time embedded systems. Their rigorous mathematical semantics allows programmers to develop critical software faster and more reliably. Synchronous languages also enable validation and verification of the developed systems. Veriest is an automatic translator that converts synthesizable Verilog designs into the synchronous language Esterel. The translation into a synchronous language can expose hidden flaws in the original design, including subtle race conditions. In addition, the extensive libraries of verified Verilog designs can now be reused in synchronous designs. Verilog and Esterel have different models and features, complicating the translation. For example, Verilog has flexible data types and operators for dealing with data buses of varying widths; it also supports three-state logic, which has no equivalent in languages not meant to describe hardware. Veriest creates functions in the hosting language (usually C) to represent concisely such features of Verilog that are not native to Esterel. Keywords: Automatic transformation, Synthesizable Verilog, Esterel.
1. Introduction Synchronous languages specify the reactions of reactive and real-time systems to their environment. They have rigorous mathematical semantics, which allows programmers to develop critical software faster and more reliably. Synchronous languages also enable validation and verification of the developed systems. They are particularly useful for designing the control of real-time embedded systems [8]. Modern hardware design is done using hardware description languages (HDLs); Verilog [6] is one of the two most popular such languages (the other being VHDL). As a result, there are many libraries of tested and verified Verilog designs available. These include many useful applications, such as communication protocols, video and audio compression algorithms, cryptographic algorithms, and more. These libraries far outnumber
corresponding libraries for synchronous languages. Many of these asynchronous designs could also be useful for designers of reactive systems that use synchronous languages, if they could be translated into these languages. These could be used to synthesize synchronous designs in software as well as hardware. In this way, designers using synchronous languages would be able to take advantage of existing asynchronous libraries instead of having to manually implement (or translate) them synchronously. Besides allowing reuse of existing designs, translating a Verilog design into a synchronous language can expose hidden flaws in the design that were not discovered by testing. Phenomena such as race conditions become obvious when stated in a synchronous language. Such translation is complicated by the difference in models between Verilog and synchronous languages. Verilog is actually composed of two main sub-languages. Synthesizable Verilog is the subset of Verilog that can be directly compiled into hardware. The rest of the language is used for designing stimulus environments (which are not a part of the design) for the simulation of synthesizable Verilog designs, and contains such features as the generation of random test vectors and assertions. Reusable Verilog designs are all written in synthesizable Verilog. This is a hardware-oriented language, and includes variable-length data types and flexible operators for combining and selecting parts of such buses. Verilog also supports three-state logic, in which a wire can be in an undriven (or “floating�) state, enabling multiple sources of control for the wire. Such features of the language have no equivalent in the target synchronous languages. We have implemented an automatic translator, called Veriest, that converts synthesizable Verilog designs into the synchronous language Esterel [4]. Esterel is one of the most popular synchronous programming languages, designed for programming reactive systems. Esterel can be compiled into sequential code as well as into hardware. Veriest preserves the Verilog RTL hardware semantics in the generated Esterel code. In order to create readable Esterel programs, Veriest attempts to keep the structure of the original program as much as possible. Some elements of Verilog can be replaced by corresponding Esterel elements in a straightforward manner. These include Verilog's one-bit variables (reg, wire), continuous and procedural assignments, conditional controls (if-else, ? :, case), values with compatible representations, module instantiation, and operators (e.g., !=, =). Features of Verilog that are not directly expressible in Esterel are implemented using Esterel's support for external Special issue
23
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
functions in the hosting language (usually C). Veriest defines a set of auxiliary functions, derived from the particular features and operations used in the source design. The function names follow a fixed scheme, so that their semantics can be immediately understood without reference to their implementation. In this way, implementation details are hidden while the design is still executable. The Verilog elements that have been handled in this way are vectors (including partial vectors), arrays, operations that depend on variable width (e.g., on groups of bits), concatenation, and tri-state signals. We have successfully translated a number of different Verilog designs using this tool. The generated Esterel code was about half again as long as the original code (excluding the generated C functions). The original intent was quite clear in the generated code, and it seemed to be understandable and maintainable. This is due to the following aspects of the translation: (1) the original code layout and variable names were preserved; (2) whenever possible, Verilog constructs were translated directly to the corresponding Esterel constructs; (3) the complexity inherent in the other part of the translation was hidden under a suitable abstraction that uses a lucid naming scheme. 1.1. The Gap Esterel is a high-level synchronous language that supports abstraction, a variety of data types and the ability to define new ones, and interoperability with other languages. It contains special constructs for timing control, and is therefore appropriate as the target language for developing reactive systems. In contrast, Verilog is meant for hardware design, and the synthesizable subset of Verilog lacks many of the abstraction mechanisms and data types of Esterel. It does emphasize timing, although in an asynchronous setting, and in that sense is closer to Esterel than most conventional programming languages. The translation of C/ C++/Java code into Esterel is not as useful as that resulting from Verilog, since the former programs are sequential, and have no timing restrictions or concurrency. The loss in such languages of the synchronization characteristics in the design makes it less suitable for a synchronous language such as Esterel. Some features of Verilog can be translated more-or# less directly into Esterel , although care must be taken to preserve the semantics. Other features pose more difficulties. Verilog supports arbitrary-width variables, with their associated operations. For example, it is possible to define 5-bit variables, and arithmetical and shift operations on such variables truncate any results to 5 bits. Similarly, it is possible to define a variable consisting of 128 bits, which is beyond the capabilities of Esterel's built-in data types. Verilog also supports flexible combinations of parts of such variables. For example, the expression {data_out [6:0], data_in} represents the value containing the seven least-significant bits of data_out with the value of data_in concatenated on the right. In hardware, such operations correspond to simple wiring, without computational content. In Esterel, these have to be represented in code. 24
Special issue
N째 1
2009
Hardware designs sometimes use tri-state (or floating) signals, which are distinct from logical high and low (or one and zero) values. The floating signals are not actively driven, so that any of a number of connected circuits can drive them in turn. This is useful in cases where one output value can result from one of several sources, each active at a different time, or when a single wire is used alternatively for input and for output. Verilog fully supports tri-state signals; for example, the expression 6'b101zzz denotes a 6-bit value whose mostsignificant 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.
2. The Translation Those constructs of Verilog that have direct counterparts in Esterel are translated separately and independently. Note that even seemingly trivial operations such as addition are complicated by the presence of data types with flexible widths. For example, the Verilog expression a+b cannot be directly translated to Esterel if the original a and b are 5-bit variables, whereas their counterparts in Esterel are integers, since truncation of the sum to 5 bits needs to be added. Unique Verilog constructs require a more detailed analysis of the Verilog source code. There are general translation solutions for each such construct, but these are sometimes overly complex. Veriest therefore attempts to recognize some frequently-used Verilog patterns, in order to translate those into more concise and efficient code. Pure Esterel can express some Verilog features awkwardly, and others not at all. For example, it is impossible to represent in Esterel a 128-bit vector using the built-in types. Five-bit vectors can be represented using Esterel integers, but correctly translating operations on them to pure Esterel requires additional operations that increase code size and obscure its meaning. To achieve a full and efficient translation we use Esterel user types [1]. These types are considered completely abstract by Esterel itself; their implementation is given in the host language. Veriest defines a set of user types with associated operations. The types and operations generated depend on the particular source program; however, they follow common patterns, and their names completely describe their semantics. Designers who want to maintain and modify the generated Esterel code therefore do not need to read the C implementation at all. We start with a small yet complete example, and then discuss the non-trivial issues involved in the translation one by one. The full details are available in [5]. Figure 1 contains a Verilog design of a simple 24-bit up-down counter. Its inputs are a clock, a counting direction selector line (dir) and a reset line (rst). Its outputs are a 24-bit bus that stores the current value and a carry for the next stage. The value of data_out is # In most of this paper we refer to Esterel version 5, which was the latest version when this work was implemented [5]. We address the changes to Esterel in Section 3.1.
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
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
N째 1
2009
incremented or decremented at each rising clock cycle, depending on whether the value of dir is one or zero, respectively. Whenever data_out overflows or underflows, it is truncated, and carry is set to one for one clock cycle. Figure 2 shows the Esterel code generated by Veriest from the Verilog design. Both Verilog wires (transient values without memory, such as clk and dir) and registers (memory devices, such as carry) are translated into Esterel as signals with boolean values. A change in the variable value causes the corresponding signal to be emitted, while the value of the variable is stored in the signal's associated value. A binary value could have been represented by the presence or absence of a signal. However, the use of a signal with a value preserves two important characteristics of Verilog register variables: first, retaining the value after the signal disappears, and second, the ability to refer to the value of the signal at the previous clock tick even while a new value is assigned to it. This capability is crucial for correct translation. Because of the need to refer to previous values, all signals are generated with appropriate initializations. The Verilog design uses procedural assignments, which have a triggering condition. In this case, the triggering condition is always @(posedge clk or negedge rst), which means that this section of code is activated on a positive edge of the clk signal or
Fig. 1. A Verilog design of an up-down counter. 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. Special issue
25
Journal of Automation, Mobile Robotics & Intelligent Systems
a negative edge of rst. This is translated into an Esterel loop that waits for a change in clk or rst. Because these are signals with values, the meaning of the statement await [clk or rst] is to wait for the existence of either signal, regardless of their values. A signal exists when a value is emitted for it. The type of change (from false to true, denoting a positive edge, or from true to false, denoting a negative edge) is checked separately, with the following if statement. This is necessary because Esterel does not support the notion of positive or negative edges of signals, and is the reason for the need to reference previous values. This treatment of signals with values whose existence indicates the assignment of new values allows the Esterel compiler to generate more efficient code, which only checks the conditions when the value is assigned, rather than at each instant. (a) Verilog source assign o1 = a | b; assign b = a;
(b) Esterel translation loop await [a or b]; emit o1(?a or ?b); end loop || loop await a; emit b(?a); end loop;
Fig. 3. Translating continuous assignments. The body of the Verilog always statement uses a number of nonblocking assignments, expressed using the <= operator. The right-hand sides of all concurrent nonblocking assignments are computed before any value is changed. In the generated Esterel code, the same effect is achieved by using the previous values of the variables on the right-hand side. Thus, the two Verilog nonblocking assignments a <= b; b <= c; would be translated into emit a(pre(?b)); emit b(pre(?c)); whereas the (sequential) blocking assignments a = b; b = c; would be translated into emit a(?b); emit b(?c);. Other than these changes, the structures of the two programs are similar. The most striking change is the treatment of the 24-bit data type used for data_out. In Verilog, the definition reg [23:0] data_out causes the addition operator in data_out + 1 to denote 24-bit addition, which truncates its result to the required length. To achieve the same result in Esterel, Veriest defines a user type called VEC_23_0. All the required operations on this data type are defined as user functions. This particular program uses addition and subtraction on 24-bit quantities, and compares them for equality. Veriest therefore defines the functions PLUS_VEC_23_0, MINUS_VEC_23_0, and COMP_EQ_VEC_23_0 for these operations. The im26
Special issue
VOLUME 3,
N° 1
2009
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 represent integers of up to 16 bits. The 24-bit vectors of the example are therefore represented as a struct of two integers, and there is no general way to specify constants of this type. The general solution in such cases is to use strings to encapsulate the constants, with conversion functions (like CONV_STRING_VEC_23_0) to create the internal representation. Of course, whenever possible, numeric constants are used. Continuous Assignment. In addition to the procedural assignments shown in the example, Verilog also supports continuous assignment statements of the form assign var = expression. Their semantics is that the variable always has the value of the expression; whenever the value of the expression changes, so does the value of the variable. In order to translate continuous assignments into Esterel, they must be placed in a loop that waits on any variable involved in the expression to change. If there are multiple continuous assignments, they are translated separately into parallel Esterel loops. Figure 3 shows an example of such translation. Variable-Width Vectors. There are two possible ways of dealing with variable-width vectors. The first is to embed them into the closest built-in integer type large enough to hold them. This makes arithmetical operations relatively straightforward, but selecting subfields and combining them to create new vectors is more difficult. The second approach is to keep each vector as a set of separate bits. This makes selection, shifting, and concatenation easier, but arithmetic becomes complex. Quite often, the same variable participates in both types of operations. Veriest takes the first approach. Each of the new types created for variable-width vectors is embedded in the next highest integer type or in a C struct of integers in case the field is too wide. As shown above, specialpurpose functions are created as necessary in order to perform arithmetical operations on the new types. Similar functions are created for selection and concatenation. A set of concatenation functions is created when variable-width vectors are combined. For example, the statement data[7:0] = {data[6:0], a} could be translated into emit data(CONCAT_INT_BOOL (CONV_INT_INT(?data, 6, 0), 7, ?a, 1)), where the second and fourth arguments specify the number of bits to take from the preceding argument. However, Veriest recognizes this pattern as a shift, and produces the more concise emit data(OR_ INT_BOOL(SHIFT_L_INT_INT(?data, 7, 1), ?a)). The second argument to the shift function is the width of the shifted field, and the third is the shift amount. Veriest recognizes the â&#x20AC;&#x153;shiftâ&#x20AC;? pattern when the same variable appears on both sides of an assignment, with some bits from either end of the vector omitted but all other bits shifted, and when another value takes the place of the missing bits. For example, this pattern will also be recognized in the statement data[7:0] = {data[6:2], a, b}, but not in data[7:0] =
Journal of Automation, Mobile Robotics & Intelligent Systems
{a, data[6:0]}, since the data is not shifted, nor in data[7:1] = {data[6:2], a}, since not all bits of data are assigned. Such heuristics are not necessary for correct translation, but they improve code readability and reduce its size. Since the goal of the translation is to generate maintainable code in the synchronous language, it is important to include such heuristics for common cases, such as shifts. For the same reason, built-in Esterel operators are used when possible. For example, Veriest will use â&#x20AC;&#x153;=â&#x20AC;? instead of the function COMP_EQ_VEC_8_0. Arrays. Verilog supports arrays of other types, and in particular arrays of registers. For example, the declaration reg [7:0] mem[0:255] defines an array containing 256 8-bit vectors. (This is a typical way to define memory.) Esterel, on the other hand, does not have builtin arrays. As in the case of vectors, the solution is to use user types. In this example, Veriest will create the type ARRAY_REG_7_0_255_0, with associated operations for reading and writing elements or ranges of arrays. Tri-State Logic. As mentioned in Section 1.1, Verilog supports a floating state for bits in addition to zero and one. In Esterel, it must be simulated using an additional bit. For each variable that may have floating bits, Veriest creates another variable that has the same name with a _Z suffix. Each bit in the new variable has the value one exactly when the corresponding bit in the original variable is in the floating state. Veriest creates code to manage both variables together in order to represent the Verilog semantics. For example, the Verilog excerpt inout [2:0] data; data = (select) ? 3'b111 : 3'bzzz;
is translated into 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
In this case, the variable data is shared between all modules that may attempt to write to it, but data_Z is duplicated for each module. A module may only write to data if it asserts in data_Z that those bits it is writing to are not floating. Note that when select is false and all bits of data are set to tri-state mode in the Verilog source, there is no need to change the value of the data variable in Esterel, since its value is irrelevant when data_Z is set to all ones. Veriest creates special comparison functions, such as COMP_EQ_Z and COMP_NEQ_Z, for comparing tri-state variables.
VOLUME 3,
N° 1
2009
lowing: the up-down counter shown in Section 2; a Viterbi encoder, an error-correcting algorithm based on convolution encoding [7]; a real-time clock; and an 2 implementation of the I C protocol for connecting multiple 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 of these examples, and discusses their implications. 3.1. Maintainability Esterel code generated by Veriest tends to be longer than the original Verilog code; the average increase in our examples was 60% (excluding the generated C functions). Generated lines also tend to be longer, due to the substitution of primitive operators such as arithmetic, selection, shifting, and concatenation, by generated functions with relatively long names. Nevertheless, most lines have a reasonable length. There are several other factors for the increase in the total size of the code. The largest overhead in the translation comes from continuous assignments, each of which needs to be translated into a loop. This is mostly due to the need to separate the triggering condition into two parts, one in the await statement listing the signals to watch, and the other in the if statement that checks the particular triggering values. Another source for the increase in size of the generated code is the difference between the control structures in the two languages. For example, Esterel lacks a case or switch statement; Verilog's case statement is therefore translated into nested ifs. A very common construct in hardware designs is a state machine, which is often implemented as a long case statement. Translating that statement into an if results in many terminating end if statements, which increase code size and decrease readability. In spite of all these factors, the increase in the total size of the code seems quite reasonable. The structure of the original design is preserved in the translated design to the best degree possible, including all module, register, and wire names. The original intent is therefore easily discernible in the generated design, making it easily maintainable. As explained above, Veriest translates part of the source Verilog design into Esterel, and part into the hosting language, C. The decision of what features to translate into which language was based on two criteria: 1. whatever can be stated concisely in Esterel should be rendered in Esterel; 2. host-language functions should have clear and simple semantics and a short and efficient implementation.
3. Results and discussion
Indeed, the meaning of the host-language functions is immediately obvious from their names. The consistent and simple naming scheme means that the Esterel designer need not see the C implementation; all the information required to understand and maintain the design is available in the Esterel source code. Also, host functions are only used when there is no equivalent Esterel
We have evaluated Veriest on four designs. These are all real and useful Verilog designs, each written by a different programmer. The example designs include the fol-
# The transformations were designed to preserve the Verilog RTL hardware semantics. We also ran simulations of the source and target programs to check their equivalence. Special issue
27
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
construct. For example, the comparison functions (like the COMP_EQ family) will not be used when the built-in Esterel comparison operator will have the same effect. Tools that compile Esterel into sequential code or hardware could also be made to take advantage of the simple and consistent naming scheme in order to produce efficient 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 data types and operators. These include bitvectors (arrays of booleans), bitvector maps (records composed of fields and bitvector slices), encoders from unsigned expressions to bitvectors, and signal arrays. These were added to the language to support “hardware or low-level software designs” [3]. These changes remove the need to use auxiliary C functions to implement operations previously unavailable. The translation can now be even more concise and readable. 3.2. Discovering Race Conditions Because of the asynchronous nature of the language, it is possible to write in Verilog designs that have race conditions. These are not flagged by the compiler, and may not be caught during simulation. Figure 4(a) shows a simple example of a race condition [2]. In this example, a rst signal sets x to 0 and y to 1. A subsequent clk signal causes a race condition, where the first always block tries to set x to the value of y while the second block simultaneously tries to set y to the value of x. However, the Verilog simulator will execute one block before the other; both orders are legal. The result will be that both x and y will have the same value: 1 if the first block is executed first, and 0 if the second block executes first. The Veriest translation of this example to Esterel is shown in Figure 4(b). Because of the synchronous semantics of Esterel, this program is illegal and the compiler rejects it with the error message “statically cyclic program, cannot be compiled by scssc.” In this simple Verilog example, the race condition is easy to spot by inspection. However, subtle race conditions in larger Verilog designs will be harder to discover. Simulation, and even hardware execution (for different reasons), may yield correct results even in the presence of race conditions, and the problem might manifest itself only under rare conditions that are difficult to duplicate. The translation to the synchronous language discovers these problems during compilation.
28
2009
The structure of the resulting translation is very close to that of the original, although it is somewhat more verbose. Experiments have shown that the results are still readable and maintainable in the target language. Some Verilog designs are more appropriate than others for automatic translation to a synchronous language. Designs of large generic processing components such as CPUs and DSPs will probably not generate useful synchronous designs. The same effects can be better achieved by coding directly in Esterel. On the other hand, hardware-oriented protocols for specific purposes, such as communication protocols and compression algorithms, are good candidates for automatic conversion and are expected to yield results comparable to our example cases. (a) A Verilog design with a race condition [2]. 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
(b) The translation to Esterel. 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
4. Conclusions
await [clk or rst];
We have presented Veriest, a translator that can convert designs in synthesizable Verilog into the synchronous language Esterel. This makes the large body of intellectual-property hardware designs available to be incorporated into synchronous designs. As an added benefit, the translation of an asynchronous design into a synchronous language can help discover subtle timing conditions that may have escaped testing in an asynchronous setting. The translation is complicated by several hardwarerelated features of the source language. These are solved by using user types implemented in the host language.
if (((?clk) and not pre(?clk)) or ((?rst) and not pre(?rst))) then
Special issue
N° 1
if (?rst) then emit y(true); else emit y(?x); end if; end if end loop end module
Fig. 4. A race condition.
Journal of Automation, Mobile Robotics & Intelligent Systems
VOLUME 3,
N° 1
2009
AUTHORS Menachem Leuchter - Computer Science Department, The Open University, Rabutzki Str. 108, 43107 Raanana, Israel. Shmuel Tyszberowicz* - 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: tyshbe@tau.ac.il. Yishai A. Feldman - IBM Haifa Research Lab, Haifa University Campus, Mount Carmel, 31905 Haifa, Israel. * Corresponding author
References [1]
[2]
[3]
[4] [5]
[6] [7] [8]
G. Berry and G. Gonthier, “The Esterel synchronous programming language: Design, semantics, implementation”, Science of Computer Programming, vol. 19, no. 2, 1992, pp. 87-152. C. E. Cummings, “Nonblocking assignments in verilog synthesis, coding styles that kill!”. In: Synopsis Users Group (SNUG), 2000. Esterel Technologies. The Esterel v7 reference manual. http://www.esterel-technologies.com/files/EsterelLanguage-v7-Ref-Man.pdf. N. Halbwachs, Synchronous Programming of Reactive Systems, Kluwer, 1993. M. Leuchter. Translating Verilog designs into the synchronous language Esterel. Master's thesis, The Open University, Israel, February 2003. http://telem.openu.ac.il/cs/msc/files/ leuchter.pdf. S. Palnitkar, A Guide to Digital Design and Synthesis, Prentice Hall, 1996. J. G. Proakis, Digital Communications, McGraw-Hill, 3rd edition, 1995. R. Shyamasundar and J. Aghav, “Realizing real-time systems from synchronous language specifications”, Real Time Systems Symposium, Work in Progress Session, Orlando, Florida, USA, 2000.
Special issue
29
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
TOWARDS THE SAFETY VERIFICATION OF REAL-TIME SYSTEMS WITH THE COQ PROOF ASSISTANT Olga Tveretina
Abstract:
2. Problem description
Hybrid systems involve the interaction of discrete and continuous dynamics. Hybrid systems have been used as a mathematical model for many safety critical applications. One of the most important analysis problems of hybrid systems is the reachability problem. In this paper we argue that the proof assistant Coq can be used for the hybrid systems verification. An example of a train crossing control is provided.
We use a hybrid automaton as a mathematical formula for describing hybrid systems. We formally define the notion of hybrid automaton. The notion of a hybrid automaton was introduced in order to extend verification methods towards the systems with continuous and discrete dynamics [1]. For simplicity, we have assumed that the number of discrete locations is finite and the vector field is Lipschitz continuous. It guarantees that the solutions of the differential equations are well defined.
Keywords: Formal methods, real-time, theorem proving.
1. Introduction Real-time embedded systems have become very important in our everyday life. Programs such as device drivers and embedded controllers must run on real-time constraints. Demand placed on the embedded systems functionality, complexity and critical nature are increasing. Hybrid systems are systems where is a significant interaction between the continuous and discrete parts and high performance specifications are to be met by the system. For example, hybrid systems arise from the interaction of discrete planning algorithms and continuous processes. Many of the hybrid systems applications are critical safe and require the guarantee of safety operation. The problem of safety verification seeks for an answer to the question: is there a potentially unsafe state reachable from an initial state? Therefore, formal verifying safety properties of a hybrid system consist of building a set of reachable states and checking whether this set intersects with a set of unsafe sets. Therefore, one of the most central problems in the analysis of hybrid automata is the problem. It checks whether all trajectories of a given hybrid system meet a given safety requirement. For systems with continuous dynamics it is very difficult to compute the set of all states reachable from an initial set. Abstraction is one of the complexity reduction techniques. It reduces the state space of a system by mapping it to an abstract set of states that preserve the actual behaviour of the system. A predicate abstraction approach for the verification of hybrid systems is represented in [2]. However, the computational cost of predicate abstraction can be too high, and for large systems practically infeasible. That is why we start from a method that decomposes the state space of a system according a rectangular grid [6]. We show applicability of our method with the verification example that we have formalized within the proof assistant. It models the gate controller of a railroad crossing. 30
Special issue
Definition. A Hybrid automaton is a tuple HS = (DS, n, S0, Inv, F, Guard, and Reset) with the following components: DS is a finite set of discrete locations; n>0 is the dimension HS. The state space of HS is S = DS × n R . Each state has thus the form (l,x), where l Î DS and x Î Rn. S0 Î S is a set of initial states. Inv: DS ® P(Rn) assigns to each discrete location l an invariant set, which constrains the value of the continuous part while the discrete part is l, i.e. continuous evaluation can go on as long as x remains in Inv(l). Guard: DS × DS ® Rn describes a guard condition, i.e. if a system remains in a discrete location l1 and a continuous state x reaches the guard Guard(l1,l2) then the discrete state may change its value to l2. F: DS × Rn ® Rn is a vector field. Reset: DS × DS × Rn ® Rn is a reset function. Definition. (Admissible function) We say that a function n n f: R ® R is admissible if there are m1 and m2 such that for all x1, x2, x3 Î Rn such that x1 = m1 x2 + (1-m1) x3 for some 0 < m1 < 1 there is 0 £ m2 £ 1 such that f( x1) = m2 f( x2) + (1-m2) f( x3). In the following we assume that functions defining continuous behaviour satisfy this property. It will be used for the proving of the correctness of the approach.
3. Transition system A system state can change in two ways: either continuously by time evaluation or by discrete transitions. Hence, there are two kinds of transitions. First one is a continuous transition, describing the evolution of a system in a given location. Second one is a discrete transition, describing movement from one location to another location and, possibly, changing the continuous variables according to the function Reset. Based on this, the semantics of a hybrid automaton is given by the following transition system [2].
Journal of Automation, Mobile Robotics & Intelligent Systems
Definition. (Transition System) Given a hybrid automaton HS = (DS, n, S0, Inv, F, Guard, Reset), the transition system Tr = {S, ® c ,® d , S0} of HS consists of the set of states S; the set of initial states S0; two relations ® c and ® d satisfying the following (l,x) ® c (l,y)Û $t ³ 0, "i, Fi(l,xi,t)=yi Ù y Î Inv(l), where x=(x1 , ... ,xn ), y=(y1 , ... , yn ) (l,x) ® d (l', y) Û (l,x) Î Guard(l, l') Ù y=Reset (l,l',x) Definition. (Trajectory) Given a hybrid automaton HS, a trajectory of HS is a sequence s1, s2, …, sm , such that for all i and j such that i>j, sj ® d sj or sj ® c sj. Given a hybrid automaton HS and a set of unsafe states U, the safety verification problem concerns with proving that all trajectories of HS cannot enter U.
4. Reachability analysis Our method is based on the approach that decomposes the continuous state space according to a n-dimensional rectangular grid. Such abstractions are mostly performed in a manual manner. In general, a state space can be represented by polyhedra [2]. This is a more flexible approach but it requires an algorithm for dealing with these polyhedra. A rectangular grid is less flexible but it is simpler to implement the corresponding operations. We assume that we have an algorithm that can proa duce a decomposition of a state space. We denote by S a set of all abstract states. In order to define a discrete abstraction of a given system, we have to describe the transitions between the abstract states, the set of initial a abstract states S 0, and the set of abstract unsafe states a U . Given a hybrid automaton HS and a set of abstract states, the set of initial abstract states can be computed. An artificial transitivity can create many false counter examples, i.e. abstract behaviours that do not correspond to any concrete ones. That is our incentive to optimise an abstract transition system from [2] by reformulating the relation defining an abstract continuous step. Definition. (Abstract Transition System) Given a hybrid automaton HS = (DS, n, S0, Inv, F, Guard, Reset), the a a a a a abstract transition system Tr = {S , ® c ,® d , S 0} of HS consists of the set of abstract states Sa; the set of initial abstract states Sa0; two relations ® ac and ® ad satisfying the following (l,x ) ® c (l,y ) Û x Î x , y Î y : (l,x) ® c (l,y) a
a
a
a
a
a a a a a (l,x ) ® d (l', y ) Û x Î x , y Î y : (l,x) ® d (l', y)
Definition. (Abstract Trajectory) Given a hybrid automaa ton HS and a set of abstract states S , an abstract a a a trajectory of HS is a sequence s 1, s 2, …, s m , such that a a a a for all i and j such that i>j, s j ® d s j or s j ® c s j. Note, that in general, an abstract trajectory starting from some initial abstract state is not unique.
VOLUME 3,
N° 1
2009
5. Modelling of hybrid systems with the proof assistant Coq Coq is an interactive proof assistant, which allows formal defining mathematical objects and helps the user with proving the properties of these objects. Basically, the use of Coq follows three steps: a) define the objects and axioms used, b) state a theorem, c) provide proof steps until the proof is completed. For more details we refer to [3]. We do not have enough space to present all formalizations in Coq that is why we present only a small part 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 lists of 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 of a railroad crossing from [4]. The model consists of two subsystems: a train and the gate controller. The train is required to send a signal app at least two minutes before it enters the crossing. The train sends a signal out when it leaves the crossing and it must happen no afterwards than 5 minutes after the app signal (this is expressed by the guard 2< x <5). The gate must be closed in at least 1 minute after the app signal is received and not later than in 2 minutes (the guard is 1< y <5). The gate responds by opening within 1 minute after receiving the out signal. We have considered a product of timed automata that combines the train process and the controller process, and the resulting system is depicted in Figure 2. It has the following discrete locations: Loc1: a train is far from the gate and the gate is open; Loc2: the train is approaching the crossing and the gate is open; Loc3: the train is approaching the crossing and the gate is closed; Loc4: the train has left the crossing and the gate is closed. We want to verify that the gate is never closed longer than 5 minutes. There are two continuous variables. Therefore, the dimension of the continuous state space is 2. Definition Dim := 2. There are four discrete states. That is modelled in Coq as following. 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 are not reachable. The full formalization of the verification approach includes also a proof of the correctness of the procedure in Coq that will use a definition of an admissible function. Due to the property described in the definition, a segment of a straight line is mapped to a segment Special issue
31
Journal of Automation, Mobile Robotics & Intelligent Systems
of a straight line. This means that for each continuous state that is in some abstract state there is a corresponding abstract transition. This proof is left for future work.
6. Conclusions and future research We have made a first step towards the fully formal verification of hybrid systems in the proof assistant Coq. The presented framework allows combination of discrete abstraction with other approaches, as "barrier certificates" for example. The train-crossing example was "model checked" in Coq. As for future work, we intend to investigate the structure of special classes, for example linear hybrid systems, for which our method is efficient. ACKNOWLEDGMENTS 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 the examples of hybrid systems formalizations in Coq. The research is supported by the BRICKS/FOCUS project 642.000.501.
AUTHOR Olga Tveretina - Institute for Computing and Information Sciences, Radboud University Nijmegen, The Netherlands. E-mail: o.tveretina@cs.ru.nl.
References [1]
[2]
[3] [4]
[5]
[6]
32
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”, Theoretical Computer Science, vol. 138, 1995, pp. 3-34. R. Alur, Th.Dang, F.Ivancic, “Reachability Analysis of Hybrid Systems via Predicate Abstraction”, ACM transactions on embedded computing systems (TECS), 2004. Y. Bertot, P. Casteran, “Interactive Theorem proving and Program Development”, Springer, 1998. T.A. Henzinger, X. Nicollin, J. Sifakis, S.Yovine, “Symbolic Model Checking for Real-time Systems", 7th Symposium of Logics in Computer Science, 1992. A. Henzinger, P.W. Kopke, A. Puri, P. Varaiya, “What's Decidable About Hybrid Automata?”, Journal of Computer and System Sciences, vol. 57, no. 1, 1998, pp. 94-124. S. Ratschan, Z. She, “Safety verification of hybrid systems by constraint propagation-based abstraction refinement”, ACM Transactions on Embedded Computing Systems (TECS), vol. 6(1), 2007.
Special issue
VOLUME 3,
N° 1
2009
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
IMPROVING DEPENDABILITY OF AUTOMATION FOR FREE ELECTRON LASER FLASH Bogusław Kosęda, Tomasz Szmuc, Wojciech Cichalewski
Abstract: Free-electron laser FLASH (260-meter-long machine) is a pilot facility for the forthcoming XFEL (3 km). Along with growth of the experiment, service and maintenance are becoming so complex that certain degree of automation seems to be inevitable. The main purpose of the automation software is to facilitate operators with computer-aided supervision of several hardware/software subsystems. The efforts presented in this contribution concern elaboration of general framework for designing and development of automation software for the FLASH. The toolkit facilitates specification, implementation, testing and formal verification. The ultimate goal of the framework is to systematize the way of automation software development and to improve its dependability. At present usefulness of the tools is being evaluated by testing the automation software for single RF-power station of the FLASH. Keywords: Automation, formal methods, model checking, expert system, Prolog, FLASH.
it work". Both aforementioned toolkits offer merely the implementation tools. They do not facilitate stages of specification, testing and verification. To address requirements of application domain, several mechanisms borrowed from expert-systems field have been used. Proposed software consists of two execution engines (see Fig. 1) supplied with the specification in the domain-specific language. The planner engine assembles plans to drive the subsystem automatically towards desired operation mode. The exception handler is designed to deal with possibly complex exceptional situations, which may be exposed by driven hardware. Its role is to fix known operation glitches and perform conflict resolution in case of multiple exceptions.
2. The architecture Single installation of the automation software consists of two runtime automation engines and two specification files. Cooperation of the engines is realized by a dedicated cooperation protocol.
1. Introduction The peculiarity of this system implies a number of requirements typical for safety-related applications [15]. The automation software for supervision of the laser equipment cannot break it due to its internal logical error. It also must not expose human personnel inspecting high power laser equipment to a risk of being injured. One of the most important requirements for customer-oriented facility as FLASH [1] is maximization of machine uptime (the time when the FLASH is utilized for the experiments). The automation software is expected to be a means for improving this factor by reducing human error and by providing automatic fault recovery. Under these circumstances liveness of the software seems to be very important too. Several attempts to automate certain subsystems of 1 the FLASH have been performed at the DESY [3,4,5,6]. 2 All of them utilized the DOOCS [2] Finite State Machine [7,3] toolkit or Stateflow [8]. Authors' practice reveals that successful applications of simple automation schemes are feasible but design of statemachines for larger subsystems turns out to be tedious and error-prone. The problem becomes particularly evident when specification evolves and design has to be updated. Then, even well elaborated statemachine becomes a mixture of complex expert's knowledge and tricky endeavours, which "make 1. Deutsches Elektronen-Synchrotron in Hamburg, member of the Helmholtz Association. 2. Distributed Object Oriented Control System.
Fig. 1. Single installation of the automation software. 2.1. Planner Engine Its role is to automate routine operation procedures usually performed by the operators. It consists of specification language interpreter, state estimator, planner and plan executor. State estimator retrieves current status of supervised accelerator subsystem. Planner synthesizes a sequence of procedures bringing the system from active state to the state satisfying specification of target operation mode. Plan executor takes care of for executing a single procedure. The specification for the planner engine is comprised of constructs presented by the grammar from Fig. 2. A state space of a finite state description is represented by set of system variables (<qvariable>) with significantly reduced domains. Physical signals readouts are introduced to the specification by means of <observable>. Mapping between the model and hardware readouts is accomplished by definition of system variables domains. Possible model state transformations are expressed by means of atomic operations (<procedure>). Special issue
33
Journal of Automation, Mobile Robotics & Intelligent Systems
Their specification consists of precondition, postcondition, reference to the executable code and estimate of execution time. Procedure is permissible only if its precondition evaluates to true. Postcondition becomes fulfilled after its successful execution. Execution time helps in estimation whether the procedure is still in progress or has presumably failed. Since every automated operation is performed on purpose, there is a way to specify possible goals of automation. For these purpose there exists a construct <opmode>. It specifies a valuation of subset of system variables, which must hold for the operation mode to be active. Specification can be augmented with definitions of formal properties of the model (<formalprop>). The only usage scenario of the planner engine is to configure target mode and let the software bring the subsystem there. This process executes in cycles. Every cycle the state estimator guesses the status of supervised device, planner finds the sequence of atomic procedures driving the system into target operation mode and plan executor performs first procedure from the plan. After reaching the target operation mode, planner engine restricts itself to monitoring. In the case of single pro-
VOLUME 3,
2.2. Handler of Exceptional Events Exception handler recognizes operation glitches and if possible executes appropriate remedy procedures. If exception cannot be dealt with automatically, it stops the automation software and warns the operators. In the case of multiple exceptions it must choose the most suitable remedy procedure. Its specification language is designed for definition of exceptional situations. They are described by means of conditions defined in terms of 3 monitored DOOCS properties. There are distinguished three categories of the exceptions. Permanent faults, temporary interrupts and warnings. Faults cause permanent break in machine operation. Interrupts are temporal glitches, which can be automatically dealt with. Warnings provide information about possibly approaching operation problems.
Fig. 2. Grammar defining syntax of the specification language for both the planner and the exception handler.
34
Special issue
2009
cedure failure several scenarios depending on plan executor setup may happen. At present there are two setups possible. First repeats failed procedure while the second tries to find and execute alternative procedure.
<specification> ::= {def <definition> ";"} <definition> ::= <repexceptions> | <exception> | <observable> | <procedure> | <qvariable> | <opmode> | <formalprop> <observable> ::= observable <obsname> of type <obstype> taken from <doocsaddr> <obstype> ::= bool | int | float | string <condition> ::= <relation> <junction> <relation> <junction> ::= & | "|" <relation> ::= <obsname> <operator> <number> | <obsname> <bitop> integer <operator> integer <operator> ::= == | != | < | > | <= | >= <bitop> ::= bitor | bitand | bitxor <number> ::= integer | float <procname>, <obsname>, <qname>, <qval>, <opname>, <pname>, <doocsaddr>, <description>, <message> ::= string <qvariable> ::= qvariable <qname> <qdomain> <q domain> ::= <qvalue> {" ," <qdomain>} <qvalue> ::= value <qval> if <condition> <opmode> ::= opmode <opname> active when <state> <state> ::= <state> {<junction> <state> } <state> ::= <qrelation> <qrelation> ::= <qname> == <qval> | <q name> != <qval> <procedure> ::= procedure <proc name> description: <description> trigger: <doocsaddr> allowed <condtype> <condition> postcondition: <condition> cost: integer <condtype> ::= unless: | when: <formalprop> ::= specification <pname> <ptype> <state> <ptype> ::= always | never | possible <repexceptions> ::= report <exctype> to <doocsaddr> <exctype> ::= fault | warning | interrupt <exception> ::= <interrupt> | <fault> | <warning> <interrupt> ::= interrupt <description> holds if <condition> report message <message> execute procedure <proc name> <fault> ::= fault <description> holds if <condition> report message <message> <warning> ::= warning <description> holds if <condition> report message <message>
3. Corresponding grammar may be found in Fig. 2.
N째 1
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
Above classification was introduced to facilitate conflict resolution in the case of multiple exceptions occurrence. If a fault occurs, automation software is permanently suspended and appropriate message is sent to operators' console. Occurrence of an interrupt in case of lack of faults entails execution of suitable remedial procedure. Conflict resolution between interrupts is based on calculation of subsumption relation. More strictly specified interrupts have precedence before more general ones. The algorithm for deciding whether one exception subsumes another utilizes two constraint solvers. The clp/bounds [12] and the clpqr [12]. The idea of calculating the relation is fairly simple. If one assumes two exceptions E1 and E2 which conditions cnd1 and cnd2. The algorithm reports the subsumption if there exist three valuations V1,V2,V3 of variables (hardware readouts) in cnd1 and cnd2 meeting one of the following statements. E1 subsumes E2 iff (cnd1(V1) Ù cnd2(V1) Ù (cnd1(V2) Ù ¬cnd2(V2)) Ù ¬(¬cnd1(V3) Ù cnd2(V3)) E2 subsumes E1 iff (cnd1(V1) Ù cnd2(V1)) Ù (¬cnd1(V2) Ù cnd2(V2)) Ù ¬(cnd1(V3) Ù ¬cnd2(V3)) When above conflict resolution methods fail, the order of appearance in the specification file decides which exception is handled first. 2.3. Cooperation Scenarios Both the runtime engines perform complementary tasks. Since they share the same hardware equipment, they must obey certain rules of cooperation. For this purpose a protocol orchestrating their collaboration has been designed. General diagram of the cooperation protocol design is presented in Fig. 3. Table 1 explains
N° 1
2009
the interfaces presented in the diagram. Figures 4 and 5 present the design of the cooperation protocol in the 4 form of Harel's statecharts [14] . Table 2 provides descrip-tions of the states from the Fig. 4 and 5. Poorly designed cooperation protocol might cause automation software to hang. Therefore it had to be verified for the deadlock [13] and livelock [13] freedom. The SPIN [11] model checker was used for this purpose. Protocol design pre-sented in Fig. 3, 4 and 5 was modelled in the PRO5 MELA language. Then the model has been checked for the exis-tence of deadlocks and livelocks. It turned out that all non-progressive cycles [11] found in the model did not cause starvation (livelock). They have been marked as progressive by inserting a progress labels depicted as numbered bullets in 4 and 5. After inserting the labels into the model no invalid endstates [11] (deadlocks) have been found. Besides, the model has been verified to conform to its functional requirements presented in Fig. 6.
3. Integrated formal verification and testing In this project, automated formal verification is realized by model checking [10]. The NuSMV [9] is a model checker used to verify formal properties included in the specification for the planner. Dedicated converter translates the model encoded in the specification language to the equivalent model expressed in the NuSMVs input language. Definitions of formal properties, which need to be fulfilled by the model, are expressed in the Computation Tree Logic (CTL) [10]. Fragmentary example of the NuSMV input specification could be seen in Fig. 7. The model of verified system is an asynchronous statemachine. Its state is described by symbolic variables defined in the module systems_state and each transition is represented by corresponding module (e.g. switch_to_manual). Module main creates all the processes. Model execution consists in sequential execution of nondeterministically chosen processes.
Fig. 3. General scheme of communication between the planner and the exception handler. 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.
Special issue
35
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
Table 1. Explanation of the data supplied to and exchanged between the parts of the protocol from Fig. 3. Stimulus name
Description
STATE_RECOGNIZED GOAL_REACHED PLAN_SUCC GOAL_AIMED AUTO_MODE GLITCH ERROR FREEZE_PLANNER FREEZE_HNDLR
State of supervised plant fits in the state space defined by the specification A state of the target operation mode has been reached A path to one of the target states has been found Target operation mode has been specified The software is permitted to supervise the plant Exception handler reports an operation glitch Exception handler reports a permanent fault Suspend the planner Suspend the exception handler
Fig. 4. Design of the communication protocol for the planner.
Fig. 5. Design of the communication protocol for the exception handler. To facilitate the process of automation design, dedicated software has been implemented. The toolbox allows simulating continuous or step-by-step execution of the planner engine. It provides the interface to display and simulate the system state and integrates automatic formal verification. Some elements of the toolbox can be seen in the Fig. 7, 8, 9. 36
Special issue
4. Conclusion Usefulness of the framework has been evaluated by implementation of supervision software for RF-power station subsystem. This installation is responsible for supplying cavities with energy necessary for particle acceleration. Unfortunately description of this complex installation is beyond of the scope of this paper. It can be
Journal of Automation, Mobile Robotics & Intelligent Systems
VOLUME 3,
N° 1
2009
Table 2. Explanation of the state names from the Fig. 4 and 5. Stimulus name
Description
P_AUTO P_FROZEN GOAL_IS_AIMED GOAL_NOT_AIMED STEP_EXECUTION PLANNING STATE_SCANNING INCOMPLETE INC_PLANNING INC_STATE_SCANNING E_MANUAL E_FROZEN AUTO UPDATE REPORTING_EVENT PROCEDURE_EXECUTION
The planner is permitted to supervise the plant The planner is suspended A target operation mode has been specified No target operation mode is specified The planner executes single step of a plan Planning in progress Planner performs state recognition Planner is incomplete Planning has failed State of the plant is unknown Both engines are suspended The exception handler is suspended The automation engines are permitted to supervise the plant Exception detection in progress All exceptions are being reported to the operator Exception handling procedure in progress
1. FREEZE_PLANNER ® ¯ Ø FREEZE_PLANNER 2. FREEZE_HNDLR ® ¯ Ø FREEZE_HNDLR 3. GLITCH ® ¯ Ø P_FROZEN 4. ERROR ® ¯ Ø P_FROZEN 5. MANUAL ® ¯ Ø P_FROZEN 6. Ø GOAL_AIMED ® ¯ GOAL_NOT_AIMED Ù E_FROZEN Fig. 6. Properties of the cooperation protocol, which prove its responsiveness and deadlock freedom. MODULE systems_state VAR FORCE_MANUAL_MODE: {FALSE,TRUE}; MODULATOR_STATUS: {LOCKED_FOR_5_MIN,ERROR,OFF,ON}; ASSIGN next(FORCE_MANUAL_MODE) := FORCE_MANUAL_MODE; next(MODULATOR_STATUS) := MODULATOR_STATUS; MODULE switch_to_manual(st) ASSIGN next(st.FORCE_MANUAL_MODE) := case st.FORCE_MANUAL_MODE = TRUE: FALSE; 1: st.FORCE_MANUAL_MODE; esac; MODULE switch_to_auto(st) ASSIGN next(st.FORCE_MANUAL_MODE) := case st.FORCE_MANUAL_MODE = FALSE: TRUE; 1 :st.FORCE_MANUAL_MODE; esac; MODULE main VAR state: proc_switch_to_manual: proc_switch_to_auto: FAIRNESS running
process systems_state; process switch_to_manual(state); process switch_to_auto(state);
-- reachability of MODULATOR_READY SPEC EF(state.FORCE_MANUAL_MODE & state.KLY_INTERLOCK_STATUS & state.MOD_INTERLOCK_STATUS & state.MODULATOR_STATUS
= FALSE = ALL_GREEN = ALL_GREEN = ON)
Fig. 7. Fragmentary specification for the planner automatically translated to the NuSMV input language. Special issue
37
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
Fig. 8. The interfaces for simulation and step-by-step execution of the automation software.
Fig. 9. The graphical user interface for observing and simulating the finite-state model of the planner for the RF power station. found in [1]. Despite the whole RF-power station is quite complex, it has simple operation scenarios. Six operation modes have been specified. They are presented in Fig. 8. The system state was described by nine system variables depicted in Fig. 9. The exception handler was supplied with the specification of the following exceptions. Personal interlock active (personal safety, permanent fault). 7 RF-leakage detected (personal safety, permanent fault). Unrecoverable modulator fault (permanent fault). Modulator power supplier switch is off (human assistance needed). Only RF-inhibit activated (remote restart possible). General modulator problem (remote restart possible). IGCT stack overheated (hardware safety, wait till temperature drops).
operation modes. It also managed to recover the RFpower station from several field quenches in the accelerating structures (only RF-inhibit activated) and modulator faults (general modulator problem). These two are the most frequently occurring exceptions, which need to be handled automatically. Response to remaining specified faults was verified by fault injection.
6
The software has been used for several maintenance days for driving the fifth RF-power station of the FLASH. It was used to drive the RF-power station to all specified 6. Personal interlock indicates potential threat to the personnel servicing the RF-power station. It also indicates presence of the personnel in the vicinity of high power microwave installations. 7. DRF-leakage is a hardware interlock signal reporting leakage of the high power electromagnetic field from the waveguide distribution system, which may cause serious injury of the person subjected to the field. 38
Special issue
AUTHORS Bogusław Kosęda*, Wojciech Cichalewski - Technical University of Lodz, Department of Microelectronics and Computer Science, Al. Politechniki 11, 90-924 Łódź, Poland. E-mail: koseda@dmcs.pl Tomasz Szmuc - AGH University of Science and Technology, Department of Automatics, Al. Mickiewicza 30, 30-059 Kraków, Poland. * Corresponding author
References [1]
[2]
[3]
Aghababyan A., Altarelli M., et al., XFEL The European X-Ray Free-Electron Laser Technical Design Report, ISBN 3-935702-17-5, 2006. Hensler O., Rehlich K., “DOOCS: a Distributed Object Oriented Control System”. In: Proceedings of XV Workshop on Charged Particle Accelerators, Protvino, 1996. Ayvazyan V., Rehlich K., Simrock S., Sturm N., “Finite
Journal of Automation, Mobile Robotics & Intelligent Systems
[4]
[5]
[6]
[7] [8] [9]
[10]
[11] [12]
[13] [14]
[15]
VOLUME 3,
N° 1
2009
State Machine Implementation to Automate RF Operation at the TESLA Test Facility”. In: Proceedings of the Particle Accelerator Conference, Chicago, 2001. Kosęda B., Cichalewski W., “Design and Implementation of Finite State Machine for RF Power Station”. In: Proceedings of the 12th International Conference Mixed Design of Integrated Circuits and Systems, Kraków, Poland, 2005. Kosęda B., Cichalewski W., “Improvements of Expert System for RF-Power Stations”. In: Proceedings of the 13th International Conference Mixed Design of Integrated Circuits and Systems, Gdynia, Poland, 2006. Brandt A., Cichalewski W., Koseda B., Simrock S., “Automation of low level RF control operation for the VUV-FEL at DESY and future accelerators”. In: Proceedings of SPIE, Photonics Applications in Industry and Research, IV 5948, 2005. Wagner F., Modeling Software with Finite State Machines: A Practical Approach, ISBN 0-8493-8086-3, 2006. MathWorks, Inc., Stateflow and Stateflow Coder User's Guide. Cimatti A., Clarke E., et al., “NuSMV 2: An OpenSource Tool for Symbolic Model Checking”. In: Proceeding of International Conference on Computer-Aided Verification, Copenhagen, Denmark 2002. Huth M., Ryan M., Logic in computer science, Modelling and Reasoning about Systems, ISBN 0-521-54310-X, 2004. Holzmann G., SPIN Model Checker, The: Primer and Reference Manual, ISBN: 0-321-22862-6, 2004. Wielemaker J., SWI-Prolog 5.6 Reference Manual. Available at: http://gollem.science.uva.nl/SWI-Prolog/ Manual/. Free On-Line Dictionary of Computing. Available at: http://foldoc.org/. Harel D., Statecharts: A Visual Formalism for Complex Systems Science of Computer Programming, vol. 8, 1987, pp. 231-274. Storey N., Safety Critical Computer Systems, Addison Wesley, ISBN 0-201-42787-7, 1996.
Special issue
39
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
USING PRE-EMPTION FOR DEPENDABLE URBAN VEHICLE TRAFFIC Tiberiu Letia, Sergiu Barbu and Florin Dinga
Abstract: A new approach for design and implementation of urban vehicle control system is proposed. The vehicle streams on lanes are considered similar with the streams of instructions in multitask programs. Real-time scheduling algorithms are used to allocate the green lights to phases. An adaptive component is used to calculate new vehicle flow parameters when a failure appears as a consequence of an accident. The real-time schedulers use the parameters to obtain new feasible resource allocations. Keywords: urban vehicle traffic control, real time scheduling, traffic congestion, real time control, dependability.
1. Introduction Urban vehicle traffic control is one of the most complex problems due to the large number of variables or parameters involved and their unexpected variations. There are controlled inputs (by the traffic lights) and uncontrolled inputs (vehicles that enter on the current lane from parking or from streets uncontrolled by traffic lights). The flow of the vehicle stream can be measured by appropriate detectors (or sensors). Vehicle presence can be detected and occupancy can be measured. The unmeasured inputs and outputs (from/to parking places) introduce non deterministic factors. The flow splits (in intersections) can be measured or estimated but cannot be controlled in an acceptable manner [8]. Better traffic control leads to improved safety for all road users, shorter travelling times through the controlled part of the traffic system and it also reduces negative environmental impact [11]. Therefore, vehicle traffic control systems have to face: variable inputs (part of them controllable) represented by the vehicle flows entering the systems, variable transfer splits of the flows on the intersections and accidents that significantly modify the parameters. These require the achieving of adaptive control systems that take into account the variable ratio of the rates with the aim to maintain a high throughput and to reduce travelling time. The control system gets information about traffic from the detectors and controls it using the traffic lights.
2. Approaches of Urban Vehicle Traffic Control The cycle of an intersection is a sequence of all (traffic lights) signals that are applied to open sequentially all the lanes that enter the crossroad. The cycle duration is the time interval from application of a traffic light signal (starting of the cycle) of a phase until its next application. 40
Special issue
A phase is a part of the intersection cycle allocated to any specific movement receiving the right-of-way or to any combination of traffic movements receiving the rightof-way simultaneously during one or more intervals. Usually, the intersection cycle duration is split into phases that open the input lanes such that the corresponding flows cross the intersection. The flow split refers to the ratio by which an input lane flow is divided into several output flows. Urban vehicle traffic control can be actuated or nonactuated. Control can be non-coordinated (implemented for isolated intersections) or coordinated. The actuated urban vehicle traffic control can be implemented using the following approaches: controlling the flows (i.e. the volume control), density control, queue length control, singular event reaction, phase time extension until a minimum gap out, and phase time extension until timeout. The solution for vehicle traffic control problem contains: the intersection cycle durations (if such cycles are chosen), the durations of phases (the split of the cycle) and their periods if there are no cycles, the order of phases (of each intersection) or their priorities, and the offsets (between intersections or phases). Papageorgiou et al. present some methods for local, centralized or distributed control of vehicle urban traffic [14]. Bazan [3] presents a coordination method based on multi-agent system that uses game theory to get the crossing times and the synchronization of intersection signalling. The negotiation method can also be used [8]. Intelligent vehicle traffic management can be used, too [6]. Non artificial intelligent coordination methods are often based on optimization [15]. Kutil et al. use a model of a simple traffic intersection where the state variables represent the queue length and the average waiting times in the queues to obtain a fair traffic control [7]. They use the balancing waiting times to obtain a linear quadratic regulator and a nonlinear model predictive controller. Liu and Tate propose an intelligent adaptation speed system that uses in-vehicle electronic devices to enable the speed of vehicle to be regulated automatically [12]. This offers a flexible method for speed management and control in urban area. Avella et al. present a method to solve the shortest path problem under resource constraints for vehicle fleet on a road net [1]. The majority of approaches (using deterministic or heuristic methods) consider the vehicle traffic system as working under probable (often previously measured and statistically expressed) conditions. But as a matter of fact, the demand (required green light) times and the granted durations (of neighbour intersections green
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
lights) can vary considerably from instance to instance and are not known completely at the moment of the decision making. Even when these are known, the proposed methods are based on the estimated time demands of the traffic and on the probable values (splits) of the rates.
3. Pre-emption Based Control of Urban Vehicle Traffic Unlike the previous ones, another approach is based on the worst case behaviour of the system. That means the usage in design of the highest accepted demands and the highest requirements relative to the timelines instead of the corresponding probable values. The usage of real-time scheduling methods to signal control of the traffic lights in urban vehicle traffic is introduced in [9]. Vehicle flows on the lanes associated to an intersection phase are considered similar with the stream of instructions (of a task) that has to be processed by a processor. Each vehicle stream has its own period (that can be different from the periods of other phases of the same intersection) and duration to cross the intersection. The proposed method is a feedback control. Its implementation fulfils real-time constraints. The resulted vehicle flows are expected to fulfil timing constraints too. Figure 1 represents the vehicle streams of the traffic system.
Fig. 1. Example of urban vehicle traffic net. Lu et al. present a feedback control real-time scheduling framework for adaptive real-time systems [13]. They use feedback control theory to design algorithms
N째 1
2009
that satisfy the transient and steady state performance of real-time systems. One of the main problems of urban vehicle traffic control has to solve the scheduling of resources representing the places used by vehicles on lanes or intersections (most critical resources). The scheduling algorithms can be categorized as static or dynamic. In static scheduling algorithms have complete knowledge about stream set and its constraints (such as deadlines, crossing times, precedence constraints and future demand times). In dynamic scheduling the algorithms have no complete knowledge about stream set or its timing constraints. dynamic scheduling algorithms can be divided into algorithms that work in sufficient resource environment and those that work in insufficient resource environment. The traffic congestion is an example when the system reaches a state in which, at least for the moment, the available resources are insufficient. Figure 2 shows the temporal relations between the demanded moments of time (dt) and green light durations of two consecutive intersections i-1 and i. Each of them should be opened within a specified period (T). The offset (O) between them also has to be implemented. The jitter (J) appears due to variation of vehicle speed or opening of the (linked) phase from the previous intersection. The opening of a phase before the demand moments of time (dt) is useless. If the end of the crossing time (C) is after the deadline (dd) this can lead to congestion. When a phase is opened at the dt (just when the vehicle stream arrives), because the vehicles have the desired speed (they are moving), the throughput is higher. This leads to a higher usage of the intersection (representing a critical resource). If the demanded durations are higher than the granted durations for some periods of time, this leads to congestions, also because lane capacities are exceeded. Figure 3 describes the UML (Unified Modelling Language) state machine of a phase from an intersection. The switching of the phases is performed by the implementation of the real-time scheduler by updater (Figure 4) and dispatcher (Figure 5). They can implement different types of real-time schedulers used to control the urban vehicle traffic systems. The updater calculates the waiting times (w) and adds the phases (using add (phase) method) to the ready queue when they expire. It also calculates the number of requests (req) of each phase that are not honoured.
Fig. 2. Temporal relations between phases of two consecutive intersections. Special issue
41
Journal of Automation, Mobile Robotics & Intelligent Systems
VOLUME 3,
N째 1
2009
Fig. 3. UML state machine of an intersection phase.
Fig. 4. UML state machine of Updater.
Fig. 5. Time driven dispatcher UML state machine.
-
-
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 the Figure 5 has to be extended with a new state and transitions to catch the demand events. 42
Special issue
Fidge describes the most largely used real-time scheduling methods and their tests [4]. A review of realtime scheduling methods is given in [16]. Between them are: RMS (rate monotonic scheduling), EDF (earliest deadline first) and SPS (static priority scheduling). Using such scheduling methods for the network of intersections composing urban vehicle traffic system, a system that fulfils some specified timing constrains is obtained. An output lane is fed by one or more input lanes. If there are more input lanes, one of them (usually the one with the highest vehicle rate) is chosen as main input lane. The opening moment of the main input lane of the current intersection should be correlated with the opening moment of the output lane (transformed in an input lane in the next intersection). When the vehicle platoons released (periodically) from the main input lane of the current intersection arrive at the waiting queue of the next intersection, it is desired to find the corresponding phase already open such that a green wave is obtained. If this requirement cannot be fulfilled, the corresponding phase of the next intersection should be opened not later than the deadline. This deadline is calcu-
Journal of Automation, Mobile Robotics & Intelligent Systems
lated such that the number of vehicles that entered on the lane that links these two intersections does not overflow (at any time) its capacity. The real-time scheduling algorithm chooses between available (ready) phases the one which has to be currently opened according to the intersection policy using the phase (lane or flow) parameters.
4. Dependable Urban Vehicle Traffic System Taking into account the article of Avizienis et al. [2], the dependability of an urban vehicle traffic system is given by the following attributes: availability (readiness for usage - i. e. the acceptance of vehicle entrance in the traffic), reliability (continuity of service - the moving of vehicles without unnecessary unbounded stops), safety (absence of catastrophic consequence on the user), confidentiality (absence of unauthorized disclosure of information, usually less important for vehicle traffic system in regular usage), integrity (absence of improper system alteration) and maintainability (ability to undergo repairs and evolutions). The failures of urban vehicle traffic system are: - failures of the control system caused by bad control decisions, message transmissions or signalling of events or states; - failures of traffic systems (distributed controlled process) caused by exceeding of specified demands or driver's faults that lead to accidents. The vehicles that remain inside an intersection after their phase loses the right of crossing (green lights), because they cannot enter the output lanes, involve congestions [10]. Their number multiplied by a coefficient dependent on the structure of the intersection can be used as a measure of the current degree of congestion. The average values of the congestion degrees of all intersections of the traffic system provide information about current congestion degree of the entire system. The evolution of the average congestion degree can be used to evaluate the traffic system behaviour under the imple-
VOLUME 3,
N째 1
2009
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 the blocked lanes. As a consequence, new parameters should be provided to traffic lights controller (based on scheduling algorithms) to adapt to the modified environment and having the goal to avoid the congestion of the system. The congestion of an intersection can lead to the congestion of the entire traffic system if it is highly loaded with vehicles. The on-line control uses the estimation of flows based on the measure of flow inputs and the flow splits. Using the real-time scheduling algorithms, the control system estimates if the necessary crossing times lead to a feasible solution (that fulfils the timing constraints). The local controllers receive the parameters (offset, period, green duration and priority) of each phase and implement the on-line schedulers that send the signals to the traffic lights. The centralized adaptive algorithm activated at the detection of a failure is: for all intersections Estimate or receive from local controllers the splits of the rates. for all intersections for all phases Calculate the necessary crossing time. while (feasibility if schedulling is not fulfilled) Reduce the crossing time of each phase proportionally with its global priority, but not lower than a specified limit. Communicate to local controllers the new scheduling parameters. end
Fig. 6. Traffic simulator window. Special issue
43
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
5. Testing and evaluation The performance evaluation of urban vehicle traffic system can be developed from the concepts of real-time systems given by [5]. The evaluation can be based on: qualitative binary criteria, qualitative gradual criteria and quantitative criteria. 1. Qualitative binary criteria are: timelines (the ability to meet some specified deadlines), no unbounded delay nor arbitrarily long crossing (or travelling) times, functional correctness, permanent readiness, all applicable physical constraints and congestion prevented. 2. Qualitative gradual criteria are: safety, reliability, availability, congestion, simplicity, and fault tolerance, graceful degradation on the occurring of undesired events, portability (of the control system), flexibility (to change of the vehicle traffic structure) and extensibility (of the control system with the development of the traffic net). 3. Quantitative criteria are: worst case travelling times on a specified path, worst case crossing times of an intersection, worst case duration to detect the failures and to correct the consequences (speed of adaptation), capacity (throughput) reserves and transfer capacities (throughput) of road net system or intersections. To evaluate the proposed control method a special urban vehicle traffic simulator was built as can be seen in Figure 6. It uses the microscopic method for simulation of vehicles on lanes and a macroscopic method to evaluate the number of vehicles inside intersections. The simulator is able the calculate the congestion degree of each intersection taking into account the number of vehicles that remain inside the intersection after the traffic lights of the lanes they leave change to the red light, and the intersection structure. The values of the current number of vehicles (inside intersection) and the intersection congestion degree are displayed on the intersection rectangle. The current number of vehicles contained into the entire system is printed on the upper side of the window. The simulator has buttons to modify the input flows of the traffic system and to choose different schedulling algorithms. The average intersection congestion degrees are used to evaluate the entire vehicle traffic system congestion degree. This degree as well as the total number of vehicles that remain inside the traffic system after the transitory regime can be used to evaluate the control performances of the different control algorithms. Figure 7 presents the variations of the total numbers of vehicles (steady state) with the input flows, using the algorithms EGT (classical extended green time), RMS and EDF respectively. The lowest value of the number of vehicles characterises a traffic system with higher vehicle throughput. Figure 8 shows the steady state relationships relating the input flows' changes to system congestion degree using the same algorithms. The lowest congestion degree corresponds to the best control algorithm. Relative to the considered (practical measured) regular values of the traffic rates (corresponding to around 44
Special issue
N째 1
2009
50% of vehicle generator frequency), the input flows were increased and decreased by the vehicles generator of the simulator. Each time, the number of vehicles that remain inside the simulated traffic system after the transitory regime is stored and so is the system congestion degree. They are represented in Figure 7 and Figure 8. Similar graphics were analysed for the system dependability.
Fig. 7. Variations of steady total vehicle numbers with input flows.
Fig. 8. Variations of the system congestion degrees with input flows. Figure 7 shows that EDF algorithm leads to a lower number of vehicles moving into the system, so the traffic system throughput is higher. Figure 8 shows that RMS and EDF algorithms have lower congestion degrees (close to each other) compared to classical EGT algorithm. When the traffic rates have low values the differences between these three algorithms are not significantly different from the point of view of throughput and congestion. The realtime schedulling algorithms (EDF and RMS) work better in the range of 50-80%. The system congestion degree is lower at the upper input flow values due to the fact that the vehicles that exceed the system throughput capacity are stopped to enter into the traffic controlled area.
6. Conclusions The urban vehicle traffic dependability can be improved by specification, design of the control system and synthesis of the control algorithms. Observations of the
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
urban vehicle traffic behaviour when failures appear are useful to obtain better specification of description and requirements. Models that describe more closely the behaviour of drivers when failures appear should be used to improve the requirements of the control system. The proposed method uses different periods for the phases of the same intersection. Usually, the periods of phases linked in a path should be correlated. Further studies should be developed to find the need (the effect) of modification of phase periods at the failure appearance. The local priorities are used to schedule or analyse the feasibility of critical resources scheduling. The global priorities are used to determine the global behaviour of the traffic system. They serve to maintain the main features of the system when failures appear. The relations between global priorities and quantitative criteria (for traffic performance evaluation) are to be studied with the aim to improve dependability. The performance evaluation results (from simulations) demonstrate that the proposed algorithms provide better transient and steady state performance when traffic volumes are at low values when traffic failures appeared. At high volumes, the controlled traffic system has better performances with real-time scheduling algorithm, but without a throughput reserve the control system is not able to correct completely the effect of failures. The necessary reserve is depends on the place of the expected failure and the current volumes of neighbour flows.
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
AUTHORS Tiberiu Letia*, Sergiu Barbu and Florin Dinga Technical University of Cluj-Napoca, Departament. of Automation, 15 C. Daicoviciu St., 400020 Cluj-Napoca, Romania, tel: +40-264-438282, fax: +40-264-592055. E-mails: tiberiu.letia@aut.utcluj.ro, E-mails: barbu_sergiu@yahoo.com, E-mails: florindinga@yahoo.com. * Corresponding author
[16]
N° 1
2009
fic management models”, Proc. of ESIT, 2000, pp. 36-44. Kutil M., Hanzalek Z. and Cervin A., “Balancing the waiting times in a simple traffic intersection model”. In: Proc. of 11th IFAC Symposium on Control in Transportation Systems, 2006 (to appear). Letia T., Astilean A., Hulea M., Valean H., “Flow price based vehicle traffic distributed control”. In: Proc. of the 2nd International Workshop on Discrete-Event System Design, 2004, pages 91-96. Letia T., “Real-time approaches of urban vehicle traffic”. In: IEEE-TTTC International Conference on Automation, Quality and Testing, Robotics, 2006, pp. 346-350. Letia, T.: “Avoidance of urban vehicle traffic congestions”. Proc. of 11th IFAC Symposium on Control in Transportation Systems, Elsevier Publishing, vol. 11, part 1, 2006, pp. 183-189. Lindley J. A., “Urban freeway congestion: Quantification of the problem and effectiveness of potential solutions”, Institute of Transportation Engineers Journal, vol. 57, 1989, no. 1, pp. 27-32. Liu R., Tate J.:, “Network effects of intelligent speed adaptation systems”, Transportation, vol. 31, 2004, pp. 297-325. Lu C., Stankovic J. A., Son S. H., “Feedback control realtime scheduling: framework, modelling and algorithms”, Real-Time Systems, vol. 23, 2002, pp. 85-126. Papageorgiou M., Diakaki C., Dinopolou V., Kotsialos A., Wang Y., “Review of road traffic control strategies”, Proceedings of the IEEE, vol. 91, 2003, no. 12, pp. 2043-2067. Porche I., Lafortune S., “Dynamic traffic control: decentralized and coordinated methods”, IEEE Conference on Intelligent Transportation Systems, vol. 9-12, 1997, pp. 930-935. 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 Historical pers-pective”, Real-Time Systems, vol. 28, 2004, pp. 101-155.
References [1]
[2]
[3]
[4]
[5]
[6]
Avella P., Boccia M., Sforza A., “Resource constrained shortest path problems in path planning for fleet management”, Journal of Mathematical Modelling Algorithms, vol. 3, 2004, pp. 1- 17. Avizienis A., Laprie J. C., Randel B., Landwehr C., “Basic concepts and taxonomy of dependable and secure computing“, IEEE Trans. on Dependable and Secure Computing, vol. 1, 2004, pp. 11-33. Bazzan A. L.C., “A distributed approach for coordination of traffic signal agents”, Autonomous and MultiAgent Systems, vol. 10, 2005, pp. 131-164. Fidge C.J., “Real-time schedulability tests for preemptive multitasking”, Real-Time Systems, vol. 14, 1998, pp. 61-93. Halang W., Gumzej R., Colnaric M., Druzovec M., “Measuring the performance of real-time systems”, The International Journal of Time-Critical Systems, vol. 18, 2000, pp. 59-68. Kirschfink H., Hernandez J., Boero M., “Intelligent trafSpecial issue
45
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
INCORPORATING FAULT TOLERANCE INTO COMPONENT-BASED ARCHITECTURES FOR EMBEDDED SYSTEMS Shourong Lu, Wolfgang A. Halang
Abstract: A component-based software architecture is presented to support the process of designing and developing faulttolerant computerised control systems. To this end, we combine an idealised fault-tolerant component, the C2 architecture style and protective wrappers, and embed fault tolerance techniques into component definitions. The resulting architecture is described by normal- and abnormal-activity components aiming to support a wide range of fault tolerance features. Use of this architecture enables to reason about system dependability already from the earliest development stages on, and to customise fault tolerance strategies according to application characteristics. Keywords: software engineering, software architecture, fault tolerance, and component technique.
1. Introduction Fault prevention, fault tolerance, fault removal, and fault forecasting are the four main means to attain the various attributes of dependability [4]. Fault prevention and fault tolerance aim to prevent introducing faults, or to avoid service failures when faults occur. Fault removal and fault forecasting, instead, mean to reduce number and severity of faults, and to estimate present and future incidences and consequences of faults. Among them, fault tolerance is the most promising mechanism to meet the dependability requirements. Fault-tolerant systems work under the assumption that they contain faults (e.g., made by humans while developing or using systems, or caused by aging hardware), and aim to provide specified services in spite of faults being present. Fault tolerance depends on redundancy, fault detection, and recovery. Many fault-tolerant systems are complex because of redundancy, re-configurability, and various interactions between their components. This complexity has a strong impact on system architecture, as fault occurrences have to be taken into account from the earliest design stages on of systems required to be dependable. Therefore, architecture design is a crucial aspect for faulttolerant systems, as indicated by well-known safety mechanisms such as masking, dynamic redundancy, and design diversity (e.g., N-version programming, recovery blocks) [8]. Component-Based Software Engineering (CBSE) focuses on producing software systems by composing prefabricated components, which can improve the productivity and quality of target systems. In recent years, the emphasis of research on and practice in CBSE has changed from functional aspects to non-functional ones. 46
Special issue
Particularly, dependability of component-based systems is considered as one of the most crucial non-functional properties in CBSE. To cope with complexity and fault tolerance requirements, it may be beneficial to combine in their development process well-established fault tolerance techniques with component techniques, as well as to employ the Unified Modeling Language (UML) [10] to describe component-based software architecture models providing fault tolerance. In a component-based system, the software architecture specification captures system structure by identifying architectural components and connectors, and required system behaviour by specifying how components and connectors are intended to interact. It is desirable that all components show only their normal behaviours. However, certain abnormal behaviours exist when some unexpected conditions occur. In CBSE, the abnormal behaviours of components are usually represented by a set of exceptions defined by the component developers. It is impossible to eliminate all abnormal behaviours, but one can reduce them, and handle them properly after their occurrences. The main goal of this paper is to design a comprehensive architecture to develop faulttolerant systems from components. By embedding fault tolerance mechanisms into an integration architecture, normal and exceptional behaviours of system components are specified. The body of this paper is organised as follows. Section 2 briefly introduces an idealised fault-tolerant component meeting the architecture style C2 as defined in [7]. Section 3 describes the integration of idealised faulttolerant components and the C2 architecture. Section 4 presents the main activities of designing fault-tolerant systems out of components.
2. An idealised fault-tolerant component and C2 architecture style An idealised fault-tolerant component [5] is a structuring concept for coherent provision of fault tolerance in a system as shown in Fig. 1 (a). It includes both normal and abnormal responses in the interface between interacting components. Idealised fault-tolerant components communicate through request or response messages, only. On receiving a service request, an idealised component will react with a normal response if the request is successfully processed, and with an external exception, otherwise. Such an external exception may be due to an invalid service request, in which case it is called interface exception, or due to a failure in processing a valid request, in which case it is called failure exception. Internal exceptions are associated with errors detected
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
Fig. 1. Idealised fault-tolerant component and C2 architecture style. within a component that may be corrected, allowing the operation to be completed successfully; otherwise, they are propagated as external exceptions. C2 is a software architecture style for systems with intensive user interfacing. The style is component-based, and supports large-grain re-use and flexible system composition, emphasising weak bindings between components [7]. A C2 architecture as shown in Fig.1 (b) consists of software components and connectors, which transmit messages between components. Components maintain state, perform operations, and exchange messages with other components via two interfaces (named top and bottom). Each interface consists of a set of messages that may be sent or received. Inter-component messages are classified into two types, viz. requests to a component to perform an operation, and notifications that a given component has performed an operation or changed state. In the C2 architectural style, both components and connectors have a top and a bottom interface. Systems are composed in a layered style, where a component's top interface may be connected to the bottom interface of a connector, and its bottom interface may be connected to the top interface of another connector. Each side of a connector may be connected to any number of components or connectors.
3. Integration of idealised components into C2 Guerra et al. [3] introduced the concept of the â&#x20AC;&#x153;idealised C2 Componentâ&#x20AC;? (iC2C), depicted in Fig.2, as an equivalent, in structure and behaviour, to the idealised fault-tolerant component. The latter's purpose is to structure the architectures of component-based software sys-
tems compliant with the C2 architectural style. Service requests and normal responses of an idealised fault-tolerant component are mapped as requests and notifications in the C2 architectural style. Interfaces and failure exceptions of an idealised fault-tolerant component are considered subtypes of notifications. An iC2C is composed of five elements: NormalActivity and AbnormalActivity components, and iC2C top, iC2C internal, and iC2C bottom connectors. The NormalActivity component processes service requests and answers them through notifications. It implements the normal behaviour, responsible for error detection during normal operation, and the signalling of interface and internal exceptions. The AbnormalActivity component is responsible for the exception handlers (error recovery) of the iC2C, and the signalling of failure exceptions. While an iC2C is in its normal state, the AbnormalActivity component remains inactive. When an exceptional condition is detected, it is activated to handle the exception. In case the exception is successfully handled, the iC2C returns to its normal state and the NormalActivity component resumes processing. Otherwise, a failure exception is signalled to components in lower layers of the architecture, which become responsible for handling it. The iC2C top connector encapsulates the interaction between the iC2C and components located in upper levels of an architecture. It is responsible to guarantee that service requests sent by the Normal-Activity and AbnormalActivity components to other components located in upper levels of the architecture are processed synchronously, and that response notifications reach the intended destinations. The iC2C top connector also performs doSpecial issue
47
Journal of Automation, Mobile Robotics & Intelligent Systems
main translation, converting incoming notifications to a format the iC2C understands, and out-going requests to a format the application understands. The iC2C internal connector is responsible for message routing inside the iC2C. The destination of a message sent by the internal elements of the iC2C depends on its type, and whether the iC2C is in a normal or abnormal state. The iC2C’s bottom connector connects it with the lower components of a C2 configuration, and serialises the requests received. Once a request is accepted, this connector queues new requests received until completion of the first one. When a request is completed, a notification is returned, which may be a normal response, an interface exception, or a failure exception.
4. Extending the iC2C architecture by fault tolerance mechanisms The proposed architecture is constructed by adding fault tolerance mechanisms to normal- and abnormalactivity components as shown in Fig.3. The fault tolerance mechanisms are responsible for detecting errors or suspicious activities, and for executing appropriate recoveries whenever possible. The incorporation of fault tolerance mechanisms into the iC2C architecture requires re-defining normal and abnormal activities. 4.1.
Definition of the NormalActivity component In the iC2C architecture, the NormalActivity component encapsulates a desired functionality (normal activity). It may represent both a single component and a configuration established through connectors. To embed error detection mechanisms into the NormalActivity component, the concept of protective wrappers, known to be the most general approach to develop fault-tolerant systems based on COTS components, is employed. Compo-
Fig. 2. An idealised C2 component. 48
Special issue
VOLUME 3,
N° 1
2009
nent wrapping is a well-known structuring technique, and a cost-effective solution to many problems in component-based software development [2]. In our extension, a set of detectors is wrapped as iC2C connectors connecting the normal activity component, which is viewed as redundant software, and responsible for (1) detecting exceptional conditions anticipated by the specification and signalling them by raising exceptions in the provided interface of the exception component, and (2) signalling other exceptional conditions specific to the implementation of the component, by raising exceptions. This set consists of well-defined error detectors concerned with special purposes such as “FailStop Processor”, “Acknowledgment”, “I Am Alive”, “Are You Alive” [6]. When a constraint violation is detected, the detector sends an exception notification to the AbnormalActivity component. In addition to error detectors embedded in the NormalActivity component, an exception component is required to specify the raising of local and co-operating exceptions, i.e., signalling of an appropriate exception. Hence, an exception component is designed working as an extra information holder, and keeping information about application exceptions, which are used by the other components. In other words, the exception component interacts with the handler, concurrency and strategy component located in the AbnormalActivity component in order to obtain and update information about exception occurrences and handling. The exception component should have the required interface for getting information and the one for updating information. The former allows the application and other components to obtain information about exception occurrences, whereas the latter allows its clients to update information about exceptions.
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
Fig. 3. Extending the iC2C architecture by fault tolerance mechanisms.
4.2.
Definition of the AbnormalActivity component Raising an exception results in an interruption of a component's normal activity, followed by a search for an appropriate exception handler to deal with the exception signalled. Therefore, the AbnormalActivity component can be defined as an exception handling mechanism as shown in Fig.3 aiming for error recovery. When an exception is raised, the exception handling mechanism begins to work. It should be able to find and activate an exception handler to recover from errors, and to put the system back into a coherent state. Abnormal behaviour is not restricted to failures of a single component, but also associated with invalid interactions between two or more components, and with combinations of component failures. An intra-component exception is raised by an individual component. The strategy to deal with it is based on local exception handlers, which are associated to a component's implementation. Their main responsibility is to cope with anticipated exceptions, which are more related to the component's application domain, and are declared in its requi-
red interfaces, i.e., they are responsible to handle the external exceptions of the component's required interfaces and the internal exceptions raised by the component's implementation. When possible, the handlers should implement forward error recovery to mask the exceptions. Inter-component exceptions are raised by component configurations. The strategy to deal with them has to consider the integration of pre-existing components into a new configuration, and is based on co-operating exception handlers. These are associated with hierarchical structure, and deal with exceptions that could not be handled within the single components. The handlers are responsible for providing error recovery and masking by means of redundant components in the configuration, and resolving failure semantics mismatches between server components and their clients. They should be capable of dealing with all exceptions signalled by a server component. Upon receiving an exception from a server component, the handlers should try to mask it invoking the same operation on a redundant (replicated or diversely designed [1]) server component, in case it is Special issue
49
Journal of Automation, Mobile Robotics & Intelligent Systems
available. The handlers are also responsible for translating unmasked exceptions from the server component's domain to the client component's domain, before propagating them to client components. Exceptions requiring no further adaptation are automatically propagated. When direct propagation is not possible, a new exception is created wrapping the unmasked exceptions raised by the server component. As there are intra- and inter-component exceptions, the architecture is designed to consist (see Fig. 3) of HandlerComponent (HC), ExceptionHandlingStrategyComponent (EHSC), and ConcurrentExceptionHandlingComponent (CEHC). The ExceptionHandlingStrategyComponent is responsible to locate the different handlers required to resolve an exception. It implements services related to the strategy for exception handling. Hence, its responsibilities are deviation of control flow and search for handlers. It plays a central role in the architecture, and interacts with all other components. From Exception-Component it receives information about an exception occurrence while searching for its corresponding handler. Its provided interface provides the service for handler search. The handling and propagation of an exception depends on whether it is an intra-component exception or an inter-component one. For the former, the handling is limited within the component's AbnormalActivity. If the exception cannot be handled, then it is propagated. A handler may also explicitly re-signal the exception to a component in a layer of the architecture. An inter-component exception raised on receiving a service request by a component is not handled there, since it does not indicate that the component is faulty. Therefore, the exception is propagated to the client component, which issued the request. The client component handles the exception in the same manner as an intra-component one, because it possibly indicates a fault within the client component. The strategy to search for handlers of intra- and inter-component exceptions can be described using a pseudo-code as follows: if exception is propagated from intra-component then if local handler exists then call 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; else error detection in client component; if exception is raised (error has been found) then if local handler exists then call 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 handler end if; end if 50
Special issue
VOLUME 3,
N° 1
2009
The HandlerComponent is constructed with a set of handlers to cope with abnormal activities, i.e. it is responsible for fault masking and recovering. After a handler is found, EHSC asks the HandlerComponent to invoke the exception handler. According to the hierarchical structure, handlers may be associated with a component, a connector, or a configuration, as well as with exceptions themselves (default handlers). A default handler is executed when there is not a more specific handler in an application. The HandlerComponent has a required interface, which allows the EHSC to invoke a handler when the appropriate handler has been found. If an exception reaches the lowest level of an architecture, the handler for the entire system should be executed. The ConcurrentExceptionHandlingComponent is designed for concurrent co-operative actions, which use the services provided by the exception handling strategy in order to carry out the strategy for concurrent exception handling. When co-operating exceptions are raised during an action, the exception resolution is accomplished by this component. It has a provided interface, which is accessible by applications to create concurrent co-operative actions. To design co-operative component activities using nested atomic actions, it is described how each individual component is involved in such activities, and cooperative exception handling for all participants in each action 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 are components. Then, only co-ordinated recovery needs to be activated within the participant tasks of a group. This obviously restricts system design, but enables to regard each group as a recovery region, and to attach fault tolerance activities to each group participant. Each group has participants, which may be activated by some external activities, e.g., tasks, and which cooperate within the group's scope. Participants execute object methods that should have been designed to work co-operatively by means of shared objects. Participants may enter asynchronously into a group activity, but should exit in a synchronised way. Each group participant has a set of exception handlers that are designed to recover the group co-operatively from eventual errors. If any suitable handler has not been defined at least in one of the group participants, an “abort exception” is raised and, then, the group activity must be undone (backward error recovery), and such an exception must be signalled to the enclosing group. If the backward error recovery is not executed successfully within the group, a “failure exception” is signalled to the enclosing group. Exceptions can be raised by participants during an action. Some of them can be handled internally by a local handler attached to the participant that raised an exception. If an exception occurrence is not handled internally by a participant, then all action participants should handle it co-operatively. A set of co-operating exceptions is associated with each action. Each participant has a set of handlers for (all or part of) these exceptions. Participants are synchronised and probably different handlers for the same exception had to be invoked in the different participants. These handlers are executed
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
concurrently, and co-operate in handling the exception in a co-ordinated way. Therefore, we employ local handling at the level of individual components. If local handling does not succeed, an exception is propagated to the level of an action in which this component is involved to be handled co-operatively. When action-level handling is not possible, an exception is propagated to the containing action. The newly defined AbnormalActivity component encapsulates the exception handling mechanisms (intracomponent and inter-component exception handling). After implementation, it requires an interface, which should have the function handleException(). If an exception is successfully handled, handleException() returns a message, which is sent to the NormalActivity component. Then, processing is resumed. Otherwise, an exception is raised in the body of handleException().
5. Conclusion With the concept of the extended iC2C we aim to add fault tolerance mechanisms to the NormalActivity and AbnormalActivity components of an iC2C. In our approach, error detector and exception components are encapsulated into the NormalActivity component, with error detectors contained by a wrapper. These detectors are responsible to verify that messages do not violate the acceptable behaviour constraints specified for a system. The exception handling mechanism is embedded into the AbnormalActivity component. The advantage of integrating fault tolerance techniques into the process of designing and developing computer control systems required to be dependable is that appropriate fault tolerance techniques can be selected from a set of mechanisms provided and customised according to application characteristics. This approach will enhance the safety of control systems. Employing its built-in extension mechanisms, UML can be extended to suit dependable applications with respect to aspects such as error detection, error recovery, or configuration of redundancy measures. Thus, for each aspect to be modelled, the most expressive techniques can be selected by the user. Furthermore, UML and the here specified extensions constitute an effective environment to design dependable computer control systems in a comprehensive way taking fault tolerance into account throughout the entire development process.
[3]
[4]
[5] [6] [7]
[8] [9]
[10]
N° 1
2009
2004, pp. 165 - 173. Guerra P.A. de C., Rubira C.M.F., de Lemos, R., “An Idealized Fault-Tolerant Architectural Component”. In: Architecting Dependable Systems, LNCS, SpringerVerlag, 2003, pp. 21 - 41. Laprie J.-C., “Dependability: Basic Concepts and Terminology”. In: Proc. 25th IEEE Intl. Symp. on Fault-Tolerant Computing, IEEE Computer Society Press, 1995, pp. 42 - 54. Lee A., and Anderson T., Fault Tolerance: Principles and Practice. Springer-Verlag, 1990. Saridakis T., “A System of Patterns for Fault Tolerance”. In: Proc. EuroPLoP. Taylor R.N., Medvidovic N., Anderson K.M., Whitehead E.J., Robbins J.E., Nies K.A., Oreizy P.D., and Dubrow L.A., “Component - and message-based architectural style for GUI software”, IEEE Trans. on Software Engineering, vol. 22, issue 6, 1996, pp. 390 - 406. Torres-Pomales W., Software Fault Tolerance: A tutorial, NASA/TM-2000-210616, 2000. Xu J., Randell B., Romanovsky A.B., Rubira C.M.F., Stroud R.J., and Wu Z., “Fault tolerance in concurrent object-oriented software through coordinated error recovery”. In: Proc. Symp. on Fault-Tolerant Computing, 1995, pp. 499 - 508. Unified Modeling Language: Superstructure. OMG document ptc/2003-08-02, 2003.
AUTHORS Shourong Lu* and Wolfgang A. Halang - Fernuniversität in Hagen, Chair of Computer Engineering, 58084 Hagen, Germany. E-mails: Shourong.Lu@FernUni-Hagen.de, Wolfgang.Halang@FernUni-Hagen.de. * Corresponding author
References [1]
[2]
Anderson T., Lee P.A., “Fault Tolerance: Principles and Practice”. In: Dependable Computing and Fault Tolerant Systems, vol. 3, Springer-Verlag, 1990. Anderson T., Randell B., Romanovsky A., “Wrapping the Future”. In: Proc. 18th IFIP World Computer Congress, Special issue
51
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
FAULT SENSITIVITY OF EXPLICIT DMC AND GPC ALGORITHMS Piotr Gawkowski, Maciej Ławryńczuk, Piotr Marusak, Janusz Sosnowski, Piotr Tatjewski
Abstract: This paper studies dependability of software implementation of DMC (Dynamic Matrix Control) and GPC (Generalised Predictive Control) Model Predictive Control (MPC) algorithms. Explicit formulation of algorithms is considered in which the control laws are calculated off-line. Dependability is evaluated using software implemented fault injection approach. Tests are performed in the control system of a remotely controlled robot vehicle used in nuclear plants.
meters than the step-response ones. The paper is structured as follows. First, in Section 2, the case study is presented. The investigated control algorithms and their explicit formulations are shortly characterised in Section 3. Next, Section 4 presents the fault injection test bed, experiment set-up and some new aspects of adapting experiments to control algorithms specificity. Finally, Section 5 discusses experimental results and the paper is concluded in Section 6.
2. Remotely controlled vehicle Keywords: dependability, fault injection, process control, and predictive control.
1. Introduction Faults (transient, permanent or intermittent) appearing 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 in contemporary technologies. Hence, an important practical issue is to evaluate dependability of software applications in the presence of faults. It is particularly critical in many reactive systems (e.g. nuclear plants, satellites, aircrafts, chemical industry, medicine). One kind of such applications, erroneous behaviour of which might have some serious consequences, are control algorithms. This paper studies dependability of software implementations of explicit versions of DMC (Dynamic Matrix Control) and GPC (Generalised Predictive Control) Model Predictive Control (MPC) algorithms. The investigation is based on software implemented fault injection, which has been adapted to reactive applications [1,6]. In particular, a new approach to test result qualification is proposed. MPC is recognised as the only advanced control technique, which has been very successful in practical applications [14,15,16,17,21]. As MPC algorithms use models of processes for calculation of the control policy they can be successfully applied to processes, which are difficult to control. In particular, processes with significant time delay for which the PID controller does not give satisfactory control performance. Among different MPC techniques, DMC [4] and GPC algorithms [3] are the most popular. Both algorithms use linear models. The DMC algorithm uses a non-parametric model consisting of step-response coefficients of the process. Such a model can be easily obtained in industry, but to precisely describe a process many coefficients are needed. The GPC algorithm uses a parametric model in the form of a discrete difference equation. Usually, such models are significantly less complicated in terms of the number of para52
Special issue
The case study process for this research is a remotely controlled robot vehicle for nuclear plants [5] shown in Fig. 1. The vehicle must act reliably in a hazardous and unsafe environment. Application of such vehicles can significantly reduce radiation exposure to personnel and improve maintenance programme performance. Discretetime model of the process is (the sampling time is 0.5 min) y(k)=b9u(k–9)–b10u(k–10)–a1y(k–1)–a2y(k–2)
(1)
where b9= 0.022276, b10= 0.019823, a1= -1.683638, a2= 0.704688 are parameters. Input u of the controlled process relates to the voltage applied to the vehicle's engine. The vehicle model limits the voltage range to [-5;5]. Output y of the process is the velocity of the vehicle. Values of y at each sampling instant are considered to be the result of the whole application and are subject to correctness analysis. The considered process has significant time delay. For such processes the classical PID controller usually does not give satisfactory control. That is why MPC algorithms are used.
Fig. 1. Remotely controlled robot for nuclear plants.
3. Model predictive control In the MPC algorithms [14,15,16,17,21] at each consecutive sampling instant k a set of future control increments (2)
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
is calculated assuming that for p³Nu, where Nu is the control horizon. It is usually done in such a way that the future control error values (i.e. differences between the reference trajectory and the predicted values of the output) are minimised over the prediction horizon N. The following quadratic cost function is typically used (3) where
,
are vectors of length N, is a weighting matrix, is the reference (i.e. the setpoint) and are predicted values of the output over the prediction horizon, for p=1,...,N. These predictions are calculated using a dynamic model of the process. Typically, Nu<N, which decreases the dimensionality of the optimisation problem and leads to smaller computational load. Because only the first element of the determined sequence (2) is applied to the process, the control law is (4) At the next sampling instants the prediction is shifted and the whole procedure is repeated. When a linear dynamic model of the process is used, it is possible to express the output prediction as the sum of a forced trajectory (which depends only on the future 0 input moves Du(k)) and a free trajectory y (k) (which depends only on the past) (5) where is a vector of length N. The dynamic matrix of dimensionality N´Nu is composed of step response coefficients of the model. Thanks to using a linear model and the superposition principle (5), the cost function (3) becomes a quadratic one. Hence, the vector of optimal control input increments is (6) where is a matrix of dimensionality Nu´N which is calculated off-line. 3.1. Dynamic Matrix Control algorithm In the DMC algorithm the process dynamics is described, in a convenient way, by a discrete-time, finite stepresponse model. Thus, for any sampling instant k, output of the model is (7) where sj are step-response coefficients, D is the horizon of the process dynamics. The DMC control law (3) can be expressed in the following form [14,21]
N° 1
2009
(8)
where and , are coefficients calculated off-line. The total number of parameters is D. The obtained explicit control law is a linear feedback from the difference between the set-point trajectory and values of the manipulated variable increments calculated at previous sampling instants. The structure of the explicit DMC algorithm is shown in Fig. 2.
Fig. 2. Structure of the explicit DMC algorithm. 3.2. Generalized Predictive Control algorithm The GPC algorithm uses a process model in the form of a discrete difference equation describing the process input-output relation (9) where ai, bi are coefficients and nA, nB define order of the dynamics. The GPC control law can be expressed in the following form [21]
(10)
where and , are coefficients calculated off-line. The total number of parameters is nA+nB+2. The obtained explicit GPC control law is a linear feedback from the reference trajectory, values of the manipulated variable calculated at previous sampling instants and values of the controlled variable measured at previous sampling instants. Structure of the explicit GPC algorithm is shown in Fig. 3. Comparing the structures of both studied algorithms, it is evident that in the DMC algorithm, there is only one feedback from the process output variable and D-1 feedback from values of past process input increments. In the GPC algorithm, there are feedbacks from the current process output value and last nA past values of the output increments and from last nB past values of the process input increments. The step-response usually contains a large number of elements. At the same time, the process can be described precisely enough by a discrete difference equation of a relatively low order. Hence, a model used in the GPC algorithm has significantly less parameters than the model used in the DMC algorithm (i.e. D>>nA, D>>nB). It should be stressed, however, that a non-parametric Special issue
53
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
step-response model is obtained on the basis of a simple experiment but it is necessary to conduct a full identification experiment to obtain a parametric model.
Fig. 3. Structure of the explicit GPC algorithm.
4. Fault injector and experiment set-up In order to examine the fault sensitivity of the explicit implementation of the analysed control algorithms the considered controllers are implemented as applications written in C language. These applications execute a preref defined reference trajectory (y (k)) on the process (vehicle), whose simulator is also the part of the application. The applications (one for the DMC and the second one for GPC) are then examined with the use of a fault injection test bed. It's concept is based on the software emulation of a fault during the run-time of the application under test. In this research FITS fault injector is used [10,19]. It uses standard Win32 Debugging API to control the execution of the software application under test. In the whole process the following steps can be distinguished: optional source code instrumentation of the tested application, golden run execution, experiment configuration, fault injection and results analysis. In order to assure good experiment controllability, testing areas are introduced [6]. FITS disturbs directly the application only within those areas. Here, the parts of the tested applications disturbed during the experiments (dashed box) as well as process models (not disturbed) are marked in Fig. 2 and Fig. 3. To simplify tracing fault effects the user-messages captured and collected by the FITS during experiments are inserted [19]. This mechanism provides supplementary communication between the tested application and the FITS. As a result, the tested application signals some measures related to internal variables values, output signal deviations etc. During the Golden Run (GR - reference execution without faults) the execution trace and reference results are logged. Additionally, statistic information is collected on the tested application (e.g. resource usage, code size, instruction distribution). Those measures help to interpret experimental results and to profile experiments to be done (e.g. by elimination of injecting faults into unused resources). FITS simulates faults by disturbing the running application. In this process an important issue is policy of selection the type, location and time of fault injection (fault triggering). In this study single bit-flip faults within CPU and FPU registers, applications' data and machine instruction code are considered. Faults are injected pseudorandomly in time (program execution) and space (bit position within disturbed resource, distribution over applications' memory). There is a common consensus in the literature that such fault model well mimics Single Event Upset (SEU) effects. The experience 54
Special issue
N° 1
2009
also shows that such disturbances give the most interesting results for the fault susceptibility analysis [11]. Deeper discussion upon the fault injection policy can be found in [9,11,18]. ref The input of the whole application (y (k)) is the required vehicle's velocity, a step from 0 to 1 at k=10 is considered during the tests. The DMC algorithm uses the step-response model obtained from the model (1) (the horizon of the process dynamics D=100) whereas the GPC algorithm uses directly the model (1). In both algorithms N=20, Nu=5 and p=1. The whole experiment is conducted by FITS automatically. At the end of the experiment synthetic (aggregated) results for each fault location are given. An important issue (frequently neglected in the literature) is qualification of experimental results. In case of a typical calculation-oriented application correctness of its result is usually easy. It is much more complicated for other classes of applications, especially related to real-time systems [18]. Control algorithms require complex analysis of the controlled process behaviour. Values of y at each sampling instant are considered to be the result of the whole 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 to un-handled exception, T: timed-out test. where the standard factor ISE (Integrated Sum of Squared Errors) is proposed as a measure of result (y) 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 in contemporary COTS (commercial off-the-shelf) systems, e.g. memory access violation. Analysis of fault effects requires detail information upon the faults injected and the application behaviour. FITS can provide details about every test (simulated fault injection) that allow manual replay the whole test execution. Moreover, all the events and user messages occurring during the test are recorded. The tested application is instrumented to save its outputs (here simulation results, i.e. a set of control signals in subsequent sampling instants) into separate files for each test (file names managed by FITS). This gives a possibility for deeper analysis (post-experiment) of fault effects in the correlation with the injected fault and observed behaviour for each single test.
5. Experimental results The cost of the DMC algorithm implementation is 173 bytes of binary code (50 machine instructions). At the same time, the GPC algorithm implementation takes 212 bytes (59 instructions). The main difference is the number of executed instructions, i.e. a single simulation execution of the DMC and GPC algorithms takes 121261 and 12192 machine instructions, respectively. Such a result is not surprising as the control law used in the DMC
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
Fig. 4. Summary of the experimental results. 1.4
10 1.2
um ax
1
5
0.8 0.6
0
0.4 0.2 0
-5
umin
-0.2 -0.4
-10 -0.6 5
10
15
20
25
30
35
40
45
50
55
60
5
10
15
20
25
30
35
40
45
50
55
60
20
25
30
35
40
45
50
55
60
1.4 1.8
1.2
ref
y
1.6
1 1.4 0.8
1.2
0.6
1
0.4
0.8
ref
y
0.6
0.2
0.4 0 0.2 -0.2 -0.4
0
0
10
20
30
40
50
60
-0.2
5
10
15
Fig. 5. DMC algorithm simulation results: left: slow response and big control errors (ISE=31.44); right: manipulated variable u constraint violation (ISE=23.94); solid line - golden run, dotted line - incorrect vehicle behaviour. algorithm has 100 parameters whereas the GPC control law has only 14 parameters. Fig. 4 depicts summarised results of experimental evaluation of DMC and GPC algorithms (results categories C, INC, S and T are described in Section 4) from experiments with faults located in CPU registers, static code, instruction stream, FPU and used data area. The main difference can be seen in the case of faults located in the data area used by the considered algorithms. As the DMC algorithm uses much more parameters (100) than the GPC one (14), it is more insensitive to single disturbances. It is worth noting, that both algorithms can be further hardened by introducing exception handling. In the experiments carried out, no exception handling is present. Hence, approximately 50% of faults affecting the static image of the code, executed instruction stream and CPU registers resulted in unhandled exceptions (most of them relate to memory access violations). Previous experience shows [9,11,12,13,18,19] that such behaviour can be efficiently improved. A great number of tests have been performed (more then 25000 per algorithm) and their results compared. Because of limited space only two time-plots are presented here. Fig. 5 compares simulation results of the golden
run (solid lines) and two example incorrect vehicle behaviour (dashed lines). In the first case (left figures), fault injected into static code of the DMC algorithm implementation 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 manipulated variable (u) oscillations appear (the left plot). In the second case (right figures) the responses from a different experiment with the DMC algorithm are shown (fault also injected into the static code). This time violation of the manipulated variable constraint is observed (as shown in the left graph). It would result in an oscillatory movement of the robot forward and back repeatedly. Fig. 6 shows the distribution of ISE values observed (faults located in the static code) for tests considered as unacceptable (INC). It is worth noting that both the DMC and GPC algorithms have similar distribution for low ISE values (<100). Moreover, more than 66% of the INC tests have very high ISE values (Âł100), which means that the control system is unstable. Obviously, other correctness measures should be also considered and need further development and investigation.
Special issue
55
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
50% 40% 30%
GPC
20%
DMC
10% 0% <30
<40
<50
<60
<70
<80
<90
<100
<200
<500
<1000 >=1000
Fig. 6. Distribution of ISE in incorrect category.
6. Conclusions The paper presents a novel approach to evaluation and comparison of dependability of software implementation of two most popular MPC algorithms, i.e. DMC and GPC. For this purpose software implemented fault injector is used. Explicit formulation of these algorithms is considered in which the control laws are calculated off-line. The experiments show that the performance of both algorithms is different in the case of some faults (in data), as well as their faults susceptibility. It is worth noting that robustness of software implementation can be improved by some basic software fault detection/tolerance techniques. The new measures of process behaviour are also considered to be developed. Those topics will be covered in the future research.
AUTHORS Piotr Gawkowski* and Janusz Sosnowski - Institute of Computer Science, Faculty of Electronics and Information 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 Maciej Ławryńczuk, Piotr Marusak and Piotr Tatjewski - 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
References [1]
[2] [3]
[4]
[5] [6]
56
Benso A., Prinetto P., Fault injection techniques and tools for embedded systems reliability evaluation. Kluwer Academic Publishers, 2003. Blevins T. L., Mcmillan G. K., Wojsznis M. W., Advanced control unleashed, ISA, 2003. Clarke D. W., Mohtadi C., Tuffs P. S., “Generalized predictive control - I. The basic algorithm”, Automatica, vol. 23, 1987, no. 2, pp. 137-148. Cutler R., Ramaker B., “Dynamic matrix control - a computer control algorithm”, AIChE National Meeting, Houston, USA, 1979. Dorf C. D., Modern control systems, Addison-Wesley, Reading, 1995. Gawkowski P., Sosnowski J., „Experiences with software implemented fault injection”. In: International Conference on Architecture of Computing Systems, Zurich,
Special issue
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14] [15]
[16]
[17] [18]
[19]
[20]
[21]
Switzeralnd, VDE Verlag GMBH, 2007, pp. 73-80. Gawkowski P., Sosnowski J., “Software implemented fault detection and fault tolerance mechanisms - part I: Concepts and algorithms”, Kwartalnik Elektroniki i Telekomunikacji, vol. 51, 2005, no. 2, pp. 291-303. Gawkowski P., Sosnowski J., “Software implemented fault detection and fault tolerance mechanisms - part II: Experimental evaluation of error coverage”, Kwartalnik Elektroniki i Telekomunikacji, vol. 51, 2005, no. 3, pp. 495-508. Gawkowski P., Sosnowski J., Radko B., “Analyzing the effectiveness of fault hardening procedures”. In: The 11th IEEE International On-Line Testing Symposium, 2005, Saint Raphael, France, pp. 14-19. Gawkowski P., Sosnowski J., “Analysing system susceptibility to faults with simulation tools”, Annales UMCS Informatica AI, vol. 4, 2006, pp. 123-134. Gawkowski P., Sosnowski J., “Dependability evaluation with fault injection experiments”, IEICE Transactions on Information and System, vol. E86-D, 2003, no. 12, pp. 2642-2649. Gawkowski P., Sosnowski J., Experimental validation of fault detection and fault tolerance mechanisms. In: The 7th IEEE International Workshop on High Level Design Validation and Test. Cannes, France, pp. 181-186 , 2002. Gawkowski P., Sosnowski J., “Analyzing fault effects in fault insertion experiments“, The On-Line Testing Workshop, IEEE Computer Society Press, 2001, Giardini Naxos - Taormina, Italy, pp. 21-24. Maciejowski J. M., Predictive control with constraints, Prentice Hall, Harlow, 2002. Morari M., Lee J., “Model predictive control: past, present and future”, Computers and Chemical Engineering, vol. 23, 1999, no. 4/5, pp. 667-682. Qin S. J., Badgwell T., “A survey of industrial model predictive control technology”, Control Engineering Practice, vol. 11, 2003, no. 7, pp. 733-764. Rossiter J. A., Model-based predictive control, CRC Press, Boca Raton, 2003. Sosnowski J., Gawkowski P., Lesiak A., “Fault injection stress strategies in dependability analysis”, Control and Cybernetics, vol. 33, 2005, no 2. , pp. 679-699. Sosnowski J., Lesiak A., Gawkowski P., Włodawiec P., „Software implemented fault inserters”. In: IFAC Workshop on Programmable Devices and Systems, 2003, Ostrava, Czech Republic, pp. 293-298. Sosnowski J., Gawkowski P., Lesiak A., “Fault injection stress strategies”, In: The 4th IEEE Latin - American Test Workshop 2003, Brazil, 2003, pp. 258-263. Tatjewski P., Advanced control of industrial processes, structures and algorithms, Springer, London, 2007.
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
SPEED ANALYSIS OF A DIGITAL CONTROLLER IN TIME CRITICAL APPLICATIONS PaweĹ&#x201A; PiÄ&#x2026;tek, Wojciech Grega
Abstract: Traditionally, control algorithms are designed without a consideration of their real-time implementation details. The performance of a digital control system, besides the sampling period, depends on many variables, such as the control loop execution time, jitter, complexity of the control algorithm etc. In this paper attention is focused on the interaction of the parameters of the scheduled tasks and on the performance of control loops closed with digital controller. A design approach that is based on the relative speed classification of the control system has been proposed. The approach is illustrated by the analysis of control systems developed for laboratory magnetic levitation process. Keywords: digital control, real-time control, time-critical systems, FPGA, magnetic levitation, timing model.
1. Introduction Computer-based digital controllers typically have the ability to monitor a number of discrete and analog inputs, execute complex control algorithms, and drive several outputs, all at defined, often very high, speeds. In general, computer-based digital controllers must detect external events and respond to them by taking appropriate actions. It is required that all above operations and calculations take place within the required time. This imposes timing requirements on hardware and software of the computer-based control systems. More precisely, computer-based digital controllers must have sufficient processing power, sufficient high-speed input/ output hardware peripherals and operating system, fulfilling more or less hard timing requirements and handling error conditions in a predefined way. Limited processing power combined with a non-optimised hardware and software components introduce delays and non-deterministic behaviour of the real-time system. Digital control theory normally assumes evenly spaced sampling intervals and a negligible (or constant) control delay between sampling and actuation [1]. However, this can seldom be practically achieved in a real, resource-constrained system. Time delays and timing variations in control loop execution degrade the control performance and may, in extreme cases, lead to instability. Control theory does not very often advise how to design controllers to take that limitation into account [2]. Usually, control algorithms are designed without consideration of their real-time implementation details. Designers usually try to separate the real-time aspects and the dynamics of the control system. They develop
controllers that guarantee all tasks deadlines under worst-case load and external interrupt occurrence scenario. The design of safety-critical controllers is based on this approach. Plant can be suitably controlled, but at the cost of poor computer resource utilization. However, if sampling rate bound determined by the speed of the control computer is close to the minimal required by the plant, then the sampling rate of the control system becomes time critical. For such a system the performance of the real-time operating system is essential for correct operation of the control system. It has been stated in previous work (see for example [10], [12]), that integrated approaches combining two disciplines real-time computation and control theory, results in better quality for digital control systems. This is also true for networked or multirate systems [4], [6], [9]. This problem is analysed in this paper. The notion of relative speed of the control system is introduced and illustrated, on the example of magnetic levitation (MagLev) real-time control. Control system design approach based on the relative speed system classification is proposed.
2. Relative speed of a digital-controlled plant The general scheme of a digital control system is given in Fig. 1 [11], [3]. The operation of the closed-loop system can be split into three main tasks: sampling, control algorithm computation and actuation. Models and methods used by discrete-time control theory implicitly impose the timing of the tasks in the computer implementation. The tasks are associated with the events, including timer event, termination of a data frame transmission, signals that data are ready to be read from the input devices, fault detection, etc. The tasks usually share the same processor and exchange data with each other. Although a great variety of scheduling methods is available, in this work periodic task scheduling method is assumed. The following timing assumptions are made in relation to the three main tasks of a digital control loop operation: 1. Sampling is performed at equidistant time instants given by T0, but some variation of T0 are allowed. 2. The actuation is performed instantly when the control signal u(kT0) 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"). Special issue
57
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
7. The proposed control platform (processor, peripherals hardware and operating systems) are characterized by minimal (a shortest accessible) closed -loop execution time, estimated as: (2) Fig. 1. The general scheme of a computer controlled system. A/D - analog to digital converter, D/A - digital to analog converter, Rv - reference value, C - controller. 5. For the nominal models, it is possible to estimate maximal, admissible sampling period T0 that would guarantee acceptable control performance. This sampling period can be estimated as: (1) where: - is time period for "ideal" control system, where modelling and identification errors as well as time delays and variations of time period T0 are negligible and control parameters are optimal. For "ideal" control system sampling period can be extended to the upper limit defined e.g. by the Shannon theory. - is the sampling period guaranteeing robust operation of the control system, if it is under the influence of external and internal disturbances. This sampling/control period, besides fulfilling the Shannon theorem, can be selected following one of various "rules of thumb" [1], [3], depending on the desired closed-loop system performance. 6. The performance of the closed-loop control system is a strictly monotonic function of . Any applied sampling period improves control performance. For the improvement is not observed.
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 the pseudocode of the controller task includes no more than 5-10 operations (loops are excluded). The examples of "simple" algorithms are: incremental PID or state feedback controller. If the pseudocode of the controller includes more than 10 operations or loops then the algorithm is classified as "complex". The examples of "complex" control algorithms are: time-optimal, model-reference controller, predictive controller. Fig. 2 illustrates typical timing models one can use for regularly sampled process. For the model a), sampling and actuation are performed at the same sampling time (time delay is zero). For this model we have: and so called causality rule is fulfilled. Model b) from Fig. 2 is more realistic because it takes into account that control task takes time. Control loop execution time is constant and is less than sampling period: . Causality rule is not fulfilled in this case. The causality rule can be fulfilled if actuation is performed at the next sampling instant, e.g. one step delay is assumed. It is so called Strictly Proper Control Law [5].
Fig. 2. Timing models that can be used for regularly sampled process. 58
Special issue
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
Model c) also takes into account that control task takes time, but time delay is variable and is less than sampling period: . The causality rule can be fulfilled if the actuation is performed at the next sampling instant, i.e. one step delay is assumed. The constant delay can be compensated during the algorithm design. For continuous-time design, Smith predictor can be implemented for discrete-time design, plant model augment method can be applied [3]. For model d), the observed time delays are longer than the sampling period. The control task is to complex for assumed sampling period. Both causality rule and real-time constraints are not fulfilled in this case. The plant cannot be controlled in a proper way. The relative speed of control system can be characterized by the factor
N° 1
2009
A laboratory magnetic levitation system presented on Fig. 4 was used as an example of relatively high-speed plant [7], [8]. The MagLev was chosen with regard to its specific nonlinearities and fast dynamics.
.
The following classification of control system is proposed: 1. The control system will be referred to relatively lowspeed if
(model from Fig. 2a).
Fig. 3. Moving time critical control system (A) to the medium speed class (adapting the parameters) and to low speed class (B), by changing the control platform.
2. The control system will be referred to relatively medium-speed if
(models from Fig. 2b and
from Fig. 2c). 3. The control system will be referred to relatively highspeed if
(model from Fig. 2d).
Note that high-speed execution platform applied for the process described by a slow dynamic is classified as relatively low-speed control system. A digital control system will be considered as time-critical if it is classified as relatively high-speed or relatively medium-speed. A low-speed control loop applied for fast dynamic process will be classified as relatively high-speed control system.
3. Adapting control system parameters for time-critical system
The identified parameters of MagLev process were: , . The parameters of the MagLev digital control system and its relation to the proposed relative-speed definitions are given in Table 1. This plant, when controlled by a PC or a generalpurpose microcontroller, can be classified as a relatively medium-speed system. MagLev controlled by a simple 8bit microcontroller is classified as relatively high-speed system. It is a representative example to show that: Â&#x2014; usage of more efficient control system with shorter control period T0 results in better quality of control by changing classification of system from relatively medium-speed to relatively low-speed, Â&#x2014; usage of more efficient control system with shorter control loop execution time results in better quality of control by better satisfying the causality rule. Table 1. Control system parameters for MagLev. PC
For
microcontroller
FPGA
n.a.
n.a.
the control loop is relatively high-speed
and therefore becomes time-critical. It can be classified as medium- speed system, if (Fig. 3): a) after assuming the condition is fulfilled. Non-robust control is available in this case, b) after assuming the condition is fulfilled. Applications of "simple" control algorithms become possible. Such adaptation of control system parameters is limited and in most cases cannot move the system to lowspeed class. This class can be reached by changing the control platform: using the most efficient processor, better operating system, etc. (case B in Fig. 3).
4. Example: real-time control of MagLev system
Experiments with MagLev plant controlled by two different control systems were carried out. The first configuration was based on PC computer and the second was based on FPGA circuits. Both of them were developed using an extension board consisting of the FPGA circuit. Control algorithm for PC-based control system was calculated as a controller task by MATLAB/Simulink real-time application. In this case the FPGA circuit was used only for signal generation for analog/digital and digital/analog converters and for providing data to the PC computer. In the case of FPGA-based system the control algorithm was calculated directly by the FPGA circuit. The PC was used only for monitoring the plant and logging the data. Special issue
59
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
Both control systems are presented in the Fig. 4.
N° 1
2009
A comparison of the process response (FPGA-based control system), for different control periods 700 μs and 40 μs, is presented in Fig. 6. Smaller values of the overshoot and the shorter settling time are observed in the case of MagLev controlled by FPGA-based control system with the shorter control period T0 a)
Fig. 4. Block diagram of control systems: a) PC-based, b) FPGA-based. The ferromagnetic ball has followed the changing reference signal. The square wave with 2s period was applied as the reference value. The desired centre of the ball movement was in the distance of 0.0125m from the electromagnet and the amplitude of movement was equal to 0.002m. Exactly the same parameters were used for both of the tested control systems. Digital version of PID algorithm was used for both performed experiments. The parameters of the algorithm were recalculated for the specific hardware architecture i.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 response with the response of control system based on FPGA circuit is presented in Fig. 5. The control period of 700 μs was used for both control systems. The evident improvement of control quality is observed in the case of MagLev controlled by FPGA-based controller that guarantees shorter control loop execution time .
60
b)
Fig. 6. A comparison of the MagLev process response controlled by the system based on FPGA (700 μs control period) and the system based on FPGA circuits (40 μs control period): a) complete range of desired ball movement, b) magnification of up-motion part.
a)
a)
b)
b)
Fig. 5. A comparison of the MagLev process response controlled by PC system (700 μs control period) and the system based on FPGA circuits (700 μs control period): a) complete range of desired ball movement, b) magnification of upmotion part.
Fig. 7. A comparison of the MagLev process response controlled by the system based on PC (700 μs control period) and the system based on FPGA circuits (40 μs control period): a) complete range of desired ball movement, b) magnification of up-motion part.
Special issue
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
A comparison of the process response controlled by PC computer and the control system based on FPGA circuits is presented in Fig. 7. Smaller values of the overshoot and the shorter settling time are observed in the case of MagLev controlled by FPGA-based control system with the boundary control period and the boundary control loop execution time .
[2]
[3]
[4]
5. Conclusions Digital, computer based control systems are the applications that pose the very sharp timing requirements, because digital control theory usually assumes a highly deterministic sampling. Consequently, the application of the controller performing a number of real-time tasks in the control loop makes the analysis and design more complex. The performance of a digital control system depends on many variables, such as sampling period, control loop execution time, jitter, and complexity of the control algorithm. The performance of a digital control system depends not only on the performance of its individual components but also on their interaction and cooperation. The focus of this paper was the interaction of parameters of the scheduled tasks and the performance of control loops closed over digital controller. In particular, we have proposed a new design approach that is based on the relative speed system classification and applies the following paradigm: the application platform should be selected in such a way that closed-loop execution time and process dynamics are balanced. The relative speed of the system should be located just bellow the line separating "time critical" solution, giving optimal utilization of computing system resources. The results of presented experiments have showed that both factors: reduction of the control period and reduction of the loop execution time improve quality of control for magnetic levitation system. Both solutions have located the relative speed of the MagLev control system below the "time-critical" range. The obtained overshoots and settling times were much better with FPGAbased controller. The maximal improvement of control quality was observed for simultaneously reduced control period and control loop execution time. This effect was obtained for control loop closed directly via PID control application embedded into FPGA circuit.
[5]
[6]
[7]
[8]
[9]
[10]
[11] [12]
N° 1
2009
Arzen K-E., Cervin A., Eker J., Sha L., “An Introduction to Control and Scheduling Co-design”. In: 39th IEEE Conference on Decision and Control, Australia, Sydney 12thth 15 December, 2000. Franklin G. F., Powell J. D., Emami-Naeini A., Feedback Control of Dynamic Systems, Addison-Wesley Publishing Company, London, 1994. Grega W., “Stability of Distributed Control Systems with Uncertain Delays”. In: 8th IEEE International Conference on Methods and Models in Automation and Robotics, Międzyzdroje, 2002, pp. 303-307. Middleton R. H., Goodwin G. C: Digital Control and Estimation: A Unified Approach, Prentice-Hall International, Englewood Cliffs, New Jersey, 1990. Nilsson J., Real-time Control Systems with Delays. Ph.D. Dissertation, Sweden, Lund Institute of Technology, 1998. Piątek P., Application of Specialized Hardware Architectures for Realization of Time-critical Control Tasks Ph.D. Thesis (in Polish), Grega W. - supervisor. AGH University of Science and Technology, Department of Automatics, Poland, Kraków, 2007. Piłat A., “Programmable Analog Hardware for Control Systems Exampled by Magnetic Suspension”. In: Proc. Computer Methods and Systems, Kraków, Poland, 14th16th November, 2005, pp. 143-148. Sågfors M., Optimal Sampled-Data and Multirate Control - Ph.D. Dissertation, Process Control Laboratory, Faculty of Chemical Engineering, Åbo Akademi University, 1998. Schinkel G., Rantzer A., “Sample Data with Varying Sampling Time”. In: Proceedings of European Control Conference, Porto, Portugal, September, 2001, pp. 624-628. Vaccaro R. J., Digital Control a State-Space Approach, McGraw-Hill, Inc., New York, 1995. Wittenmark B., Bastian B., Nilsson J., “Analysis of Time Delays in Synchronous and Asynchronous Control Loops”. In: Proc. of 37th IEEE Conference on Decision and Control, Tampa, USA, 12th-15th December, 1998.
ACKNOWLEDGMENTS This research has received a support from the AGH University of Science and Technology.
AUTHORS Paweł Piątek* and Wojciech Grega - Department of Automatics AGH University of Science and Technology Al. Mickiewicza 30, 30-059 Kraków (Cracow), Poland. E-mails: ppi@ia.agh.edu.pl, wgr@ia.agh.edu.pl. * Corresponding author
References [1]
Aström K.J., Wittenmark B., Computer Controlled Systems, Prentice Hall, London, 1997. Special issue
61
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
TASK JITTER MEASUREMENT UNDER RTLINUX OPERATING SYSTEM Pavel Moryc, Jindrich Cernohorský
Abstract: This paper deals with real-time task jitter measurement under RTLinux operating system. In the first part, it describes methods and tools developed to measure jitter in the RTLinux environment. In the second part, it is focused on discussion of results, obtained on PC hardware, and their interpretation. Keywords: real-time, jitter, latency, measurement, RTLinux, benchmark, workload effects, saturation method.
1. Introduction: Applicability of Linux in Real-Time Systems In a real-time system there is a conflict between periodic and aperiodic tasks. Aperiodicity naturally stems from noise, disturbances, delays, and all other unpredictable phenomena in the real world. A real-time operating system should not enforce strict rules that nature cannot meet, but rather provide resources that help to smooth the conflicts. Basic approaches are pre-emptivity, buffers, and priority rules. However, as a result of pre-emptivity, a high-priority task requiring a resource may be blocked to wait for medium-priority tasks that do not hold this resource. This problem is called priority inversion. Linux is neither intended, nor designed to support real-time tasks. It is a general-purpose operating system, implementing full range of API functions covered by the POSIX-1003.1 specification. A kernel providing such large scope of API services cannot meet demands of preemptivity and low latency, required in most technology control systems. To enhance kernel pre-emptivity and reduce kernel latencies, two basic approaches are used: pre-emptive patches to Linux kernel (Molnar), virtual machines (Hardware Abstraction Layers, RTLinux, RTAI Linux). RTLinux kernel implements a Hardware Abstraction Layer inserted between hardware and the Linux kernel. Essentially, it creates a virtual machine that controls the Linux kernel timer interrupt. The RTLinux can switch between the Linux kernel and other tasks [1], [2], thus making possible to solve conflicts between real-time tasks and the Linux kernel. The Hardware Abstraction Layer (HAL) controlling the system is realized in the Linux kernel space. The system as a whole is simple and fast, but barriers between real-time task and the non-real-time Linux kernel are thin, and as a result of that, the real-time part may easily get out of stability margins required. Jitter is a variable deviation from ideal timing event. 62
Special issue
Scheduling jitter is the delay between the time when task shall be started, and the time when the task is being started. Similarly, interrupt latency is a delay between the time interrupt is triggered and the time when the Interrupt Service Routine is being started. The interrupt latency varies, and therefore, it produces a jitter. Jitters result from physical phenomena in hardware (noise), from concurrent task processing (realized either in hardware or in software), and from passing the code through different branches (each conditional instruction is a potential jitter source). Kernel latency is not stable, but composed from various phenomena, most of them (if not all) showing jitters. RT-Linux is designed as a module to the Linux kernel, and therefore, it could be reasonably supposed, the RTLinux kernel can suffer from jitters inherited to the Linux kernel. Hence, thoughtful testing is of prime importance.
2. Existing measurement methods Throughout the time, many jitter measuring methods were developed and published [3], [4]. Periodic task is characterized by its starting time of execution and by the length of execution, while aperiodic task is characterized by its latency. Interrupt latency is defined as the time from generating the interrupt request to (the start of) its service routine execution. Both theory and experience requires, that a system shall be tested under load. In a technology control system, the load is caused by the specific application requirements. This creates need to test the control system with the particular technology plant. On the other hand, benchmarks are valuable in early stages of a design process to estimate, if a control system intended for the application will fit its requirements. Therefore, both model classes of technology plants and model classes of loads can be used. As a model load, heavy network or disk load is often used. Proctor [3] examines the RTLinux behaviour in a particular application (a motor control), while Dougan [4] provides latencies and jitter examination of individual elementary RTLinux mechanisms without relations to their interactions with surrounding environment (workload, controlled technology, control system hardware), and their interactions to each other.
3. Proposed measurement methods This work presents an approach based on a generalized application program. It is intended as a measuring method tightly connected with application study. Therefore, it can be reasonably assumed, that results will be useful for general engineering practice.
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
3.1. Generalized data acquisition program RTLinux in tight connection with Linux is intended for use in systems, that allow both real-time and non-realtime tasks to coexist, and it is typically applied as an interface between dedicated real-time and non-real-time IT levels. As a representative case of this class, a generalized data acquisition program has been chosen, supplied with diagnostic time stamp outputs. The application, named RT-golem, contains and integrates resources, which make possible to apply a defined workload to the system, as well as to measure how the load task is executed on the system. It implements both periodic and aperiodic tasks. The RT-golem is a part of an over-all architecture presented in Figure 1. That contains and integrates resources, which make possible to apply a defined workload to the system, as well as to measure how the load task is executed on the system. The RT-golem includes: periodic task, which is controlled by RTLinux scheduler, aperiodic task (the Interrupt Service Routine, which is installed instead the default RTLinux ISR routine). During initial tests performed with the RT-golem it was observed that excessive IRQ requests could disrupt system operation. For that reason, the RT-golem was strengthened with overload protection, so it can sustain arbitrary input IRQ rates. Based on the test results, a saturation method of measuring interrupt latency was designed, as shown in Figure 2. Interrupts are triggered by a periodic signal supplied from external generator. The incoming interrupt rate is boosted, till the time between two successive ISR routines starts decreases. When the time stops decreasing, the IRQ rate reaches its saturation point. The minimum time between two successive ISR starts equals to the interrupt latency. It consists of latency times caused both by hardware and software resources. Since the saturation imposes the maximum IRQ rate load on the measured system it is capable to accept, the method is expected to provide comparable results across various hardware platforms.
N° 1
2009
RT-golem application has been further modified, so it could be loaded more than once. This creates a possibility to load the system by more periodic tasks, each with different priority, period, time of execution and diagnostic timestamps output. It has evolved to a configurable and flexible simulation tool.
Fig. 2. ISR latency saturation method. 3.2. Advanced measurement tool: RT-golem Analysing the measurement results and RTLinux resources, it has been recognized, that a measurement tool, which encompasses the whole range of typical RTLinux resources and provides a deeper insight is needed. Based on this analysis, the following important RT-Linux characteristics have been identified: precision of the scheduler (measured as task starting time 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 characterizes hardware, and presents the basic method of communicating with both sensors and actuators. The generalized application was substantially redesigned to form an advanced measurement tool. The advanced version of RT-golem consists of a periodic task, and an interrupt service routine. The periodic task includes two threads. It is possible to set priority and period of both threads, as well as to disable one or more parts of the task. This way, it is possible to balance the workload that the RT-golem imposes on the system.
4. Experimental setup A set of comparison measurements has been performed. In particular, the effects of different additional load on different test systems have been measured, with the load 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 Fig. 1. RT-golem operation.
on two test systems, PC Dell GX 280, PC no name. Special issue
63
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
The source code of the RTLinux scheduler contains a comment [5] recommending that this scheduler should not be used for more than 10 tasks. For verification of this recommendation, an experiment was designed, where the system is heavily loaded by fifteen RT-golem tasks, and jitters of the RT-golem test task are measured. The fifteen tasks have been configured as maximum acceptable load for the system, that is, the highest load, at which the Linux kernel yet does not start reporting, lost timer interrupts. PC Dell is a workstation designed for graphical applications, while PC no name is a low-cost, low-end personal computer. Linux kernel has been configured to use only 64 MB of RAM memory. Test system configurations are presented in Table 1.
N째 1
2009
Fig. 4. Periodic task starting time, PC no name, loaded with copying files.
Table 1. Test system details.
Fig. 5. Periodic task finishing time, PC Dell, loaded with copying files.
5. Experimental results Because of limited space, only a handful of results can be presented. The first series of graphs, presented in Figures 3 through 6, show the task instance starting (or finishing) time, while the second series of graphs (presented in Figures 7 and 8) shows the statistical data. The task instance starting time is calculated from the previous task instance starting time. This means, the starting time delay impacts two adjacent values. First, the difference between the correct and delayed instance is longer, which causes the spike up on the graph, and then, the difference between the delayed and next correct instance is shorter, which causes the spike down. If both spikes are symmetrical, the second value is okay. The finishing time is calculated from the task instance starting time. Spikes on the relative starting time graphs below oscillate around 1 msec, because they show scheduling jitter that means, a difference of the actual relative starting time from the nominal value, which is 1 msec.
Fig. 6. Periodic task finishing time, PC no name, loaded with copying files.
dark: mean light: median Fig. 7. Execution time means vs. medians. PC Dell, loaded with copying files.
Fig. 3. Periodic task starting time, PC Dell, loaded with copying files. 64
Special issue
The graphs show that the RT-golem runs smoother on the Dell PC (Figures 3 and 5), than on the no name PC (Figures 4 and 6). To evaluate the outlying values, figures 7 and 8 show the mean vs. median comparison, as well as standard deviation vs. interquartile range comparison. It
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
stems from definitions of mean and standard deviation, that they are more impacted by outlying values than median and interquartile range.
N° 1
2009
ACKNOWLEDGMENTS This work was supported by the Ministry of Education of the Czech Republic under Project 1M0567.
AUTHORS Pavel Moryc*, Jindrich Cernohorský - Technical University of Ostrava, Faculty of Electrical Engineering and Computer Science, Department of Measurement and Control, Centre for Applied Cybernetics. 17. listopadu 15; 708 33 Ostrava-Poruba, Czech Republic. E-mails: pavel.moryc@arcelormittal.com, jindrich.cernohorsky@vsb.cz. * Corresponding author dark: standard deviation light: interquartile range References Fig. 8. Execution time means vs. medians. PC Dell, loaded with copying files.
[1] [2]
6. Conclusion and future work
[3]
From the results one can conclude that the heavy hard disk operation [3] imposes more load on the system than the real-time tasks load. As the load resulting from hard disk operation is quite common in the system according to POSIX 1003-13 PSE 54 profile, it can be concluded, that a) 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.
[4] [5]
FSM Labs Inc.,“Getting Started with RT Linux“, 2001. I. Ripoll et al., “WP1: RTOS State of the Art Analysis: Deliverable D1.1: RTOS Analysis”, 2002, OCERA. F.M. Proctor, W.P. Shackleford, “Real-time operating system timing jitter and its impact on motor control”. In: Proc. SPIE, vol. 4563, Sensors and Controls for Intelligent Manufacturing II, P.E. Orban (Ed.), 2001, pp. 10-16. C. Dougan, Z. Mwaikambo, Lies, “Misdirection and Realtime Measurements”, C/C++ Users Journal, April 2004. RTLinux V.3.1 source code.
There is a question, whether the real-time characteristics of the system (the measured jitter spikes) could be smoother, if the Linux kernel were ported on a CPU designed for real time. The hardware is built as a layered structure of basic hardware resources (disk, memory, processor registers, etc.), and following advanced means (instruction queues and priority rules). The advanced resources are basically the same as the resources used in operating system. These higher-level hardware resources can be seen as a hardware implementation of the operating system resources. A CPU designed for real time (DSP) has different architecture than a CPU designed for general purpose application. It is unlikely, that it could optimally support a full range POSIX 1003-1 compliant kernel. Based on performed RTLinux and Linux kernel analysis, as well as on measured results, it can be reasonably concluded that for the RTLinux/Linux operating system, a general-purpose hardware is the optimal hardware platform. Measurements performed at the level of a real-time task often provide valuable information on task jitters, but only little information on underlying causes. Therefore, it could be useful to create a small and simple HAL layer (module) in the Linux kernel, which intercepts timer interrupt and possibly other hardware means for a moment, and quickly gets and taps the diagnostic information needed. Another possible idea is, that such tool could be integrated into lower (architecture dependent) layer of the RTLinux HAL.
Special issue
65
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
ILERT - INTERNATIONAL LEARNING ENVIRONMENT FOR REAL-TIME SOFTWARE-INTENSIVE CONTROL SYSTEMS Andrew J. Kornecki, Thomas B. Hilburn, Wojciech Grega, Miroslav Sveda, Jean-Marc Thiriet
Abstract: Due to the heavily software-centric nature of modern reactive and time-critical systems, there is an increasing demand for efficient development of high quality RealTime Software-Intensive Control systems (RSIC). The study discussed in this paper is focused on the creation of international curriculum framework centred on RSIC - this important aspect of computer-system-control-software engineering education. The study explores the mechanism for involving students from multilingual, geographically separated institutions in a coordinated educational experience. It exposes them to the problems, methods, solution techniques, infrastructure, technologies, regulatory issues, and tools in the domain of dependable realtime, safety-critical, software-intensive control systems. The ultimate objective is the creation of a model RSIC curriculum, which can be used by engineering schools both in the USA and the EU. Keywords: real-time software Engineering, engineering Curricula.
1. Introduction There is an increasing importance and demand for efficient development of high quality Real-Time Software-Intensive Control systems (RSIC). Such systems need to meet stringent safety and reliability requirements and often are developed by companies operating across national boundaries. To educate modern engineers it is critical to establish a methodology for creation of multinational engineering programs, which will produce graduates capable of working efficiently in multidisciplinary teams that are engaged in international collaboration on industrial RSIC projects. Such projects typically require conformance to specific national and international standards mandated by regulatory authorities. Modern systems are heavily software-centric, implementing reactive and time-critical software, where safety is the major issue and the margin for error is narrow. Examples include aircraft avionics, air traffic control, space shuttle control, medical equipment, and nuclear power stations. It is vital for future software developers to understand basic real-time applications concepts. The area of real-time safety-critical control systems is one of the most advanced and challenging fields of computer science and engineering. The study discussed in this paper is focused on the creation of an international curriculum framework centred on RSIC. This effort is part of a project on International Learning Environment for Real-Time Software66
Special issue
Intensive Control Systems (ILERT) supported jointly by the European Commission of the EU and the USA Fund for Improvement of Post-Secondary Education (FIPSE). The study explores the mechanism for involving students from multilingual, geographically separated institutions in a co-ordinated educational experience. It will expose students to the problems, methods, solution techniques, infrastructure, technologies, regulatory 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 RSIC curriculum, which can be used by engineering schools both in the USA and the EU. This objective addresses the nations' needs for researchers and developers of real-time safety-critical systems who may be engaged in projects spanning the nations' boundaries and promoting a student-centred, transatlantic dimension to higher education and training.
2. Global aspects of the software industry International collaboration and globalisation is a key element for the nations to come together in a peaceful way. Creation of common educational experience allows young engineers to find commonalities; it promotes teamwork and collaboration in joint projects crossing the nations' boundaries. Specifically, in the area of RSIC systems used in a regulated industry, it is critical to be familiar with the variety of regulations, standards, and guidelines required for designing, implementing and approving software-intensive systems. The proposed study creates a viable vehicle for such solutions. There is a clear need to prepare professionals for international collaboration. Understanding critical issues related to RSIC, the tools and techniques used, and documentation required for approval of systems in a regulated industry is critical for the future global projects. The ILERT project is meant to support such international collaboration and consensus building.
3. Curricular issues There exists well-established guidance for the development of computing curricula [1, 2] and there is a variety of excellent engineering offered in colleges and universities on both sides of the Atlantic. However, at this time, there is no international, interdisciplinary curriculum that directly focuses on real-time control systems, dependable software development, safety, reliability, and the certification issues in highly regulated industries like aerospace, medicine, transportation, and nuclear energy. In addition, there is no curriculum that includes globalisation aspects of the modern engineering profession.
Journal of Automation, Mobile Robotics & Intelligent Systems
The current study will lead to the design of such curriculum framework, identification of implementation and assessment mechanisms, collection of data necessary to evaluate the process, and guidelines for expansion of the proposed approach to other engineering programs. These objectives are consistent with the following complementary goals: Identify a methodology for design and implementation of a transatlantic, multidisciplinary engineering program. Stimulate students to follow careers by encouraging them to consider the area of real-time safety-critical control systems and expose them to opportunities of international collaboration. Encourage the exchange of staff and students between collaborating institutions. Offer multidisciplinary and multicultural experience to students who would not otherwise have such opportunities. Provide a forum for faculty exchange of ideas on the issues of curricula building, laboratory experiments, and assessment activities. Create a foundation for Internet-based laboratory educational experiences, which will expose students from different countries to tools, methods, and techniques used in the creation of highly dependable safety critical systems for regulated industry. Stimulate the teaching staff of the European partners to develop and introduce English versions of lectures and teaching materials. Foster a strong technological and education research base.
4. Activities The two-year study, supported by the US Department of Education Fund for Improvement of Post-Secondary Education (FIPSE) and the EU European Commission, is dedicated to the creation of a unique RSIC curriculum focusing on real-time software-intensive control and safety-critical dependable systems. The ILERT project involves international collaboration of four universities, which allows for exploration of the global implication of offering transferable engineering curricula. The partners include one American and three European universities located in three different EU countries, where English is not the language of instruction (Poland, France, Czech Republic). These partners have adequate educational/ research potential; and, through their industry and international outreach, they also recognize the needs of the current and prospective labour market for real-time control education, both in Europe and in the USA. They have published on the issues related to engineering curricula improvement [3-6, 8-10]. A two-pronged approach is used. The first includes active partners' collaboration on identification of the learning objectives and outcomes, description of the curriculum core and supporting units, development of guidelines on the implementation and assessment, identification of the technology infrastructure, and the description of faculty and staff requirements, pedagogy and delivery concepts, accreditation issues and constraints, etc. On-site research by the project faculty and selected students has been enhanced by frequent communications
VOLUME 3,
N° 1
2009
and dedicated working sessions at the partners' sites. The second part of the approach is a practical case study on how the proposed framework can be implemented by the partner institutions. Identification of the existing or easily modifiable courses, which can be used as units in the RSIC curriculum, has been attempted. A description of the laboratory infrastructure, necessary administrative procedures (admission, scheduling, and credit transfer), an assessment methodology, and experimental development and delivery of a selected RSIC unit to partner institutions were undertaken. This experimental concurrent delivery, still in planning stage, will engage on-site students only. The knowledge gained from the experience and relevant observations constitute a base for establishing a dedicated international transatlantic program in Real-Time Software-Intensive Control and may serve as a framework for development of other global engineering curricula. The project deliverables include: Analysis of industry requirements for graduates of the RTSC domain; International, interdisciplinary Real-Time Software Intensive Control Systems curriculum framework; Design for a selected unit supporting the proposed RSIC curriculum with the draft of lecture materials and laboratory handouts; Plan and pilot implementation of a laboratory infrastructure allowing students to actively participate in class activities and experiments on a remote basis; Experimental concurrent delivery of the designed unit at the four partner sites; Identification of activities and data for program assessment and evaluation, and those issues and elements required to consider program accreditation; Reflection on a process and methodology for creation of multidisciplinary, transatlantic engineering programs, including guidelines for extension of the approach to other engineering programs.
5. Analysis of industry requirements Feedback from future employers of graduates is critical to the design of a curriculum, which fully matches the continuously changing job market demands. A survey was designed to get this feedback from a specific sector of industry regarding what employers expect graduates to have in terms of skills and attitudes, as well as knowledge of technical topics. This Internet based survey was solicited from a representative sample of industry engaged in real-time software-intensive control systems. The collected data were analysed and the results were used to help identify academic program educational outcomes and objectives thus preparing a base for creation of a new curriculum framework. The respondents reflected an international composition of the ILERT project representing four countries: Czech Republic, France, Poland and USA. It needs to be noted, that we had relatively weak response rate upon the initial e-mail solicitation. The reason was that in many cases the mailing was intercepted by spam filters or the respondents were too busy to commit about 15-20 minutes to fill the survey. Occasionally, the survey reached an individual who was not prepared to provide the requested Special issue
67
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
Table 1. ILERT Survey Companies. Country
Company Name
USA (12)
Avidyne, Raytheon, Hawker Beechcraft Corporation, Stuart W. Law Company, Boston Scientific, Teledyne Controls, Boeing, Honeywell Aerospace, Hamilton Sundstrand.
Poland (14)
CSN-STANEL Automatyka, ABB Corporate Research, Astor, Abis, RAControls, InTeCoFEV Polska, Pumpa, Tarbonus, Multiprojekt, Computer Systems for Industry, ComArch, INVENTIA, MPL Technology.
Czech Republic (10)
Tescan, ANF DATA, B+R Automatizace, Honeywell, Freescale Czech Republic, ADC Czech Republic, CAMEA, Flextronics Design, ANeT Ltd., Schneider Electric CZ.
France (7)
CIRTEM, National Research and Safety Institute, ST Microelectronics, IRSN Radioprotection and Nuclear Safety French TSO, Leroy Somer, Airbus S.A., Euro-Systems.
Table 2. Industrial Survey Items. Part A Items
Part B Items
A.1. A.2. A.3.
Work as a part of a multidisciplinary team Analyse, understand and define the problem Think independently and search for solutions
B. 1. B. 2. B. 3.
A.4.
Make oral presentations
B. 4.
A.5.
Write technical reports and papers
B. 5.
A.6.
B. 6.
A.7.
Communicate with people and present arguments Communicate in a foreign language
A.8.
Lead a team
B. 8.
A.9.
Understand value and cost
B. 9.
A.10.
Experience international, social, cultural and political issues
B. 10.
B. 7.
B. 11. B. 12.
B. 13. B. 14. B. 15.
information. Repeated contacts and follow-ups allowed us to receive enough data to consider the results as valid. Eventually, as a response to over 370 solicitation we received 43 responses (11% response rate). We are grateful for the companies who took part in the survey and provided us with a valuable feedback. The names of com68
Special issue
Good background in mathematics Familiarity with a specific application domain Knowledge of control theory, algorithms and applications Knowledge of system specification and design methods Knowledge of hardware design and development concepts, methods and tools Knowledge of software design and development concepts, methods and tools Knowledge of formal methods applied to system development Experience with hardware development platforms (e.g. FPGA, PLC, microcontrollers, I/O devices) Knowledge of networking components, topologies and communication protocols Proficiency in software program construction (programming language) Understanding the concept of real-time systems (timing, scheduling, RTOS services) Familiarity with software development tools and development environments (integrated development environment - IDE, compilers/ interpreters, simulators, emulators, code/test generators) Knowledge of system development process and project management Experience with hardware/software integration, including testing and verification Knowledge of quality control, validation, verification, and certification (e.g. for dependable systems)
panies are listed in Table 1. The survey, designed by the ILERT project partners, was placed on a web server and participants were invited via e-mail, phone, and personal contact to login to the survey site and provide their responses. The survey included two main categories: Part A and Part B. Part
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
A was intended to assess the importance of general skills, capabilities and attitudes of engineering school graduates when they enter the job market. Part B included items related to specific technical areas and skills. The items 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, with a possibility to provide comments. In addition to selecting responses in Parts A and B, the survey included Part C, where responders were asked to create a “wish list”, i.e. to rank the first three items in each category according to their importance for the need of their company. In Part D, the survey asked respondents to fill information regarding the company profile, size, type of projects, etc. This information was treated confidentially to be used only to analyse and create aggregated results. A detailed analysis of the results is contained in [7]. Figure 1 depicts the relative ranking of the importance of the Part A Survey items. The highest scores received items related to understanding, problems solving, creativity and teamwork. The responses underscore the need for employees capable of communicating and using modern technologies. Figure 2 shows the ranking for the Part B Survey items. The highest score received items related to knowledge of methods and techniques related to software and system design and development. The responses underscore the industry need for employees that could be efficient from day one when facing new project and adapting to new development environment.
6. Educational objectives and outcomes The industrial survey results verified the generally agreed upon set of non-technical skills and behaviours expected from engineering school graduates (oral and written communications, professional ethics, team skills, etc.). More importantly, the survey provided a starting point for designing a specific program curriculum by helping the ILERT investigators to identify the technical knowledge areas and skills required from graduating students. Discussion and analysis of the survey results led to the definition of a general set of RSIC program educational objectives and outcomes, defined in terms of the expected graduates' proficiency, specifying the profile of graduates and their competencies. We used the definitions of Program Educational Objectives (PEO) and Program Outcomes provided by the Accreditation Board of Engineering Technology (ABET). PEO are broad statements that describe the career and professional accomplishments that the program is preparing graduates to achieve. PO are narrower statements that describe what students are expected to know and be able to do by the time of graduation.
Fig. 1. Ranking of Part A Items.
N° 1
2009
Fig. 2. Ranking of Part B Items. The graduates of any high quality-engineering program are expected to meet the following general four program educational objectives [A-D]: [A] Demonstrate professionalism in their work and grow professionally through continued learning and involvement in professional activities. [B] Contribute to society by behaving ethically and responsibly, and by incorporating knowledge of history and culture into one's professional decisions. [C] Communicate effectively in oral, written, and newly developing modes and media. [D] Assume a variety of roles in teams of diverse membership. The major areas of proficiency for the graduates of an international RSIC program (3-4 years of university/ college education) have been identified based on the results of industry surveys and discussion at the consortium meetings. These areas expand the general objectives with three additional [E-G] specific to the RSIC program: [E] Demonstrate understanding of analysis and design as applied to modern software-intensive control systems. [F] Demonstrate understanding of processes and techniques and the role of modern engineering tools necessary to engineering practice as applied for creation of software-intensive systems. [G] Demonstrate understanding of quality assurance and hardware/software integration for creation of safe and dependable systems. The Program Outcomes are characteristics of the graduating students that can be evaluated at the program completion. 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 control system or component to meet desired needs (feedback, stability, system dynamics, robustness); 4. … apply advanced software engineering techniques to implement real-time concepts (timing, scheduling, concurrency, synchronization); 5. … support assurance of the quality of a softwareintensive system across its lifecycle including assurance of its dependability using established standards and guidelines (verification, validation, testing, safety, reliability, security, standards, Special issue
69
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
6. 7. 8. 9. 10. 11. 12. 13.
14.
guidelines); … integrate hardware and software on variety of platforms with various interfaces and protocols; … use a defined lifecycle process in development of software-intensive system; … function on multi-disciplinary teams; … understand professional and ethical responsibility; … communicate effectively; … work effectively in an international environment; … understand of the impact of engineering solutions in a global and societal context; … recognize the need for and engage in life-long learning including ability to pursue graduate studies; … understand contemporary issues in software engineering, especially in the RSIC area.
The program outcomes help to identify the topics necessary for preliminary curriculum design. It is critical to understand the role of general education requirements, which complements the engineering facet of the curriculum and facilitates the main objective of university mission: to produce valuable and contributing members of the society.
7. Assessment Quantitative and qualitative indicators need to be used to assess the degree of fulfilment of the planned objectives and outcomes in the proposed time-frame, based on the detailed plan of work with specific timeline and detailed deliverables. There are three categories of indicators, related to the output, the results, and the impact. The output indicators provide information elaborating the immediate and short-term effects resulting from the planned execution of the project. These include curricula design, educational events, external institutions that have benefited from the project outputs, created artefacts, and presentations shared with external audiences. The results indicators provide information on the project output and the immediate results: new cooperative initiatives, published papers, position documents generated, etc. The impact indicators measure the long-term effects: institutions implementing the proposed framework, learning tools and services created by the project, citations and references to the project documents and papers, third-party references to project outcomes, etc. Real-time software-intensive safety-critical control systems represent a rather narrow and specific education and research area. Not many courses are offered at the undergraduate and graduate level, since appropriate coverage requires a significant amount of diverse domain knowledge difficult to include in typically overloaded computer science and engineering programs.
70
Special issue
2009
fashion. The ILERT project is intended to strengthen international co-operation and the global links in engineering education. An interdisciplinary specialization in RSIC was selected to produce not only a number of educational artefacts in a domain in high demand by industry, but also (what is more important) a process and a methodology for creation of engineering programs with a compatible quality assurance and assessment process. The graduates of such programs will be better prepared to work on projects requiring interdisciplinary and multicultural viewpoints. This enhances mobility of the future workforce and facilitates their advancement and career changes. The objective of the proposed activity is not only to serve the critical population of safety-critical real-time control system developers, but also to disseminate results and provide guidelines to a broader audience of engineering education faculty. The project will capture the process and methodology used by this multidisciplinary and geographically diverse activity for potential re-use by others. The collected observation and data will provide the base and guidelines for future implementation of complete coordinated multinational engineering programs. ACKNOWLEDGMENTS The authors acknowledge the Atlantis Program support for the work on the ILERT Project (http://www.ilert.agh.edu.pl) from the European Commission (EC grant: 2006-4563/006 001) and the US Department of Education FIPSE Program (US grant: P116J060005). The authors appreciate also contribution of our colleagues Ondrej Rysavy and Petr Matousek (BUT).
AUTHORS Andrew J. Kornecki*, Thomas B. Hilburn - Embry Riddle Aeronautical University, Daytona Beach FL, USA. E-mails: kornecka@erau.edu, hilburn@erau.edu. Wojciech Grega - AGH University of Science and Technology, Krakow, Poland. E-mail: wgr@ia.agh.edu.pl. Miroslav Sveda - Brno University of Technology, Brno, Czech Republic. E-mail: sveda@fit.vutbr.cz. Jean-Marc Thiriet - Laboratoire d'Automatique de Grenoble, Grenoble, France. E-mail: jean-marc.thiriet@lag.ensieg.inpg.fr. * Corresponding author
References [1]
[2]
8. Conclusions Nearly all-engineering disciplines have segments engaged in creation of RSIC systems. The systems are implemented worldwide, which requires a well-prepared workforce of scientists and engineers, who can cooperatively address issues in a multi-disciplinary and international
N° 1
[3]
Computer Engineering 2004, Curriculum Guidelines for Undergraduate Degree Programs in Computer Engineering, The Joint Task Force on Computing Curricula, ACM IEEE Comp. Society, December 2004. (http://www.acm.org/education/CE-FinalReport.pdf ) Software Engineering 2004, Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, The Joint Task Force on Computing Curricula, ACM IEEE Comp. Society, August 2004. (http://www.acm.org/education/curricula.html ) Grega W., “Towards the Bologna-BMD Model: Poland”, in: Towards the Harmonization of Electrical and Information Education in Europe (J.M. Thiriet, editor), Nancy
Journal of Automation, Mobile Robotics & Intelligent Systems
[4]
[5]
[6]
[7]
[8]
[9]
[10]
VOLUME 3,
N° 1
2009
University 2003, ISBN 972-97738-3-1, pp. 152-158. Hilburn T.B., Humphrey W.S., “The Impending Changes in Software Education”, IEEE Software, vol. 19, no. 5, September / October, 2002. Kornecki A.J., “Real-Time Computing in Software Engineering Education”. In: Proceedings of 13th SEE&T Conference, Austin, TX, March 2000, pp. 197-198. Kornecki A.J., “Real-Time Systems Course in Undergraduate CS/CE Program”, IEEE Transactions on Education, CD-ROM Supplement, vol. 40, no. 4, November 1997, pp. 295-296. Pilat A., Kornecki A.J., Thiriet J. M., Grega W., Sveda M., “Industry Feedback on Skills and Knowledge in RealTime Software Engineering”. In: Proceedings of 9th EAEEIE Annual Conference, June 2008. (accepted for publication). Thiriet J.M., Martins M.J., Editors, Monograph: Towards the Harmonization of Electrical and Information Engineering Education in Europe - Ed. EAEEIE, August 2003, 350 pages. ISBN, book version: ISBN 972-977382-3, ISBN: CD-ROM version: ISBN 972-97738-3-1. Thiriet J.M., Robert M., Lappalainen P., Hoffmann M., Martins M. J., Seoane A., “Toward a Pan-European Virtual University in Electrical and Information Engineering”, IEEE Trans. on Education, May 2002, vol.45, no. 2, pp. 152-160. Whetten F.L., Kornecki A.J., “Distance Teaming: A Bilocated Undergraduate Program in Computer Engineering”. In: Proceedings of 13th Annual Conference on Distance Teaching and Learning, Madison, WI, 1997, pp. 361-364.
Special issue
71
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N째 1
2009
INFocus THE SPOTLIGHT on new n Blooming robots, dancing flowers Scientists from Gwangju's Chonnam National University have developed a robot plant that emits oxygen, moisture, insecticidal pesticides, and fragrance. It also has all kinetic functions and responds at stimuli from outside - like real plants. When a person or animal (or another moving object) approaches within a 40 cm radius of the robot, the buds come into bloom. Robotic plant returns to its original state when objects leave - it is enabled by using SMA - Shape Memory Alloy to make it. The flower react also for sounds louder than usual, including music, and light. It is possible because a supersonic sensor that perceives the motion and turns 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 and consists of a pot, a stem, and five buds of a flower which looks like a rose of Sharon (a national flower of South Korea). You can have a "Roses robots garden" by using a networking system. However flower robots are not new some have already been developed in the U.S., this robotic plant is currently the most advanced. Retail price is not quoted. Professor Park Jong-Oh and his team struggles with automatically change of flowers' colour. The robotic plant debuted in November at a Robot Festival at Seoul's COEX Mall. Source: http://www.engc.ac.kr/english/
Image source: www.aving.net
n Marine barber Ships also need shaving their "beards". Scientist from 10 countries under University of Newcastle co-ordination is currently constructing an autonomous robot designed for cleaning the hulls of the ships. European Union assigned 1.2 million Euros for Hull Identification System for Marine Autonomous Robotics programme - from which a robot is called HISMAR. More or less once a year a ship has to be "shaved" - all crustacea, algae, seaweeds and shells, which have pilosed a 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 to 9 billion dollars. Because the "shaving" operation is long-term and big ships need repair dock for this, special antisprouting 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 up 350 kg) and moves on 4 small wheels. A small computer embedded into robot draws its route. Cameras transmit view of surface and enable to detect damages of ship's skin plate. Robot cleans the hull by ejecting a water jet under 200-bar pressure. 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. Source: hismar.ncl.ac.uk / www.hismar.eu and Rzeczpospolita.pl
72
In the spotlight
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
n Murata Boy has a female friend Electronic parts maker Murata Manufacturing Co., Ltd., creators of the popular Murata Seisaku-kun (a.k.a. “Murata Boy”) robot bicyclist, have developed a self-balancing robot unicyclist named “Murata Seiko-chan”. The 50-centimeter tall, 5-kilogram Seikochan, which Murata says is modelled after a female kindergartener features a pair of gyro sensors that detect her posture angle. A single wheel moves the robot forward and back, and a rotating flywheel in the chest helps turn the unicycle left and right and maintain balance. In addition to ultrasonic sensors detecting and measuring the distance to potential obstacles, Seiko-chan is equipped with built-in Bluetooth capabilities and an embedded camera that transmits live video. According to Murata's press release, Seiko-chan is described as Seisaku-kun's younger paternal cousin. Source: http://trendy.nikkeibp.co.jp/article/news/20080924/ 1019000/and http://www.pinktentacle.com/ Image: courtesy of Murata Manufacturing Co. Ltd.
n More and more insect-like robots First robot that can jump like a grasshopper and roll like a ball was invented by Rhodri Armour, a PhD student at Bath University's Centre for Biomimetic & Natural Technologies, UK. One of the major challenges that face exploration robots is being able to move over rough terrain. Jumping in a similar way to the grasshopper, robot can overcome bigger obstacles than 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” is shaped like a spherical cage, which can roll in any direction, giving it the manoeuvrability of wheels without the problem of overturning or getting stuck in potholes. "Before jumping, the robot squashes its spherical shape. When it is ready, it releases the stored energy all at once to jump to heights of up to half a metre", Mr Armour said. The components of the robot were made by rapid prototyping technology, similar to that used by the RepRap machine pioneered by the University, which builds parts by "printing" layers of plastic on top of each other to produce a 3D object.
Apparently Jollbot can be used in land survey work. Inventor hopes that his brainchild will also play key role in future space exploration.
Source: University of Bath and http://www.sciencedaily.com/releases/2008/12/081204074810.htm Images: courtesy of University of Bath
In the spotlight
73
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
EVENTS WINTER-SPRING 2009
February 20 – 22
ICCMS 2009 – International Conference on Computer Modeling and Simulation, Macau, Macau. http://www.iccms.org/index.htm
20 – 22
ICECT 2009 – International Conference on Electronic Computer Technology, Macau, Macau. http://www.icect.org/
March 07 – 09
ICFN 2009 – International conference on Future Networks, Bangkok, Thailand. http://www.icfn.org
07 – 09
ICDIP 2009 – International conference on Digital Image Processing, Bangkok, Thailand. http://www.icdip.org
08 – 10
ICCAE 2009 – International Conference on Computer and Automation Engineering, Bangkok, Thailand. http://www.iccae.org/index.htm
09 – 11
INTED 2009 – International Technology, Education and Development Conference, Valencia, Spain http://www.iated.org/inted2009
25 – 27
CICAR 2009 – 6th International Conference on Computational Intelligence, Control, Automation and Robotics Bangalore, India. http://www.waset.org/wcset09/bangalore/cicar/
26 – 28
INCAMA 2009 – International Conference on Advanced Manufacturing and Automation, Krishnankoil, Tamil Nadu, India. http://www.kalasalingam.ac.in/mech/incama2009.html
27 – 29
ICWCSN 2009 – International Conference on Wireless Communication and Sensor Networks, Buenos Aires, Argentina. http://www.waset.org/wcset09/buenosaires/icwcsn/
30 – 2 April
IEEE Symposium on Computational Intelligence, Nashville, Tennessee, USA. http://www.ieee-ssci.org
April
74
02 – 04
ICC 2009 – International Conference of Computing in Engineering, Science and Informatics, Los Angeles, California, USA. http://www.fullerton.edu/icc2009/
03 – 05
ICIME 2009 – International Conference on Information, Management and Engineering, Kuala Lumpur, Malaysia. http://www.icime.org/index.htm
Events
VOLUME 3,
Journal of Automation, Mobile Robotics & Intelligent Systems
N° 1
2009
EVENTS WINTER-SPRING 2009
03 – 05
ICFCC 2009 – International Conference on Future Computer and Communication, Kuala Lumpur, Malaysia. http://www.icfcc.org
08 – 10
CATA 2009 – 24th International Conference on Computers and Their Applications, New Orleans, Louisiana, USA. http://www.isca-hq.org/CATA-2009-CFP.pdf
15 – 16
RoboBusiness, Boston, Massachusetts, United States. http://www.robobusiness.com
27 – 29
ITNG 2009 – 6th International Conference on Information Technology: New Generations, Las Vegas, Nevada, USA. http://www.itng.info
28 – 30
ICEUC 2009 – International Conference on Embedded and Ubiquitous Computing Rome, Italy. http://www.waset.org/wcset09/rome/iceuc/
29 – 30
ICICSE 2009 – International Conference on Intelligent Control Systems Engineering Rome, Italy. http://www.waset.org/wcset09/rome/icicse/
May 27 – 29
ICCIT 2009 – International Conference on Computer and Information Technology, Tokyo, Japan. http://www.waset.org/wcset09/tokyo/iccit/
June 23 – 26
ICORR 2009 – IEEE 11th International Conference on Rehabilitation Robotics, Kyoto International Conference Center, Japan. http://www.icorr2009.org/
Events
75