‘The technique is the model of discretization at the state level and the approximation of continuous state variables by discrete ones.. The state variables model comprises continuous sta
Trang 1DESIGNING A LIFT CONTROL SYSTEM
PHAM TRAN NHU!, NGUYEN VAN TRUONG?
Institute of Information Technology,
? Pedagogical University-Thai Nguyen University
Abstract In this paper, we present an application of syntactical approach given in a formal design technique for real-time embedded systems ‘The technique is the model of discretization at the state level and the approximation of continuous state variables by discrete ones The lift system presented in this paper shall be monitored and controlled by a computing system that shall respect the components, handle the events, and satisfy the usual procedures and invariants The Duration Calculus with Iteration is used in the paper to specify requirements of the system
Tóm tắt Trong bài báo này chúng tôi trình bày một ứng dụng - hệ thống diéu khién thang may - theo cách tiếp cận hình thức cho các hệ nhúng Kỹ thuật thiết kế được dùng là mô hình hoá sự rời rạc và xấp xỉ các biến trạng thái liên tục bởi các biến trạng thái rời rạc Hệ thống thang máy được giám sát và điều khiến thông qua một hệ thống tính toán nhằm quản lý các bộ phận, điều khiển các sự kiện và làm thoả mãn các thủ tục cùng những bất biến đặc trưng cho hệ thống Tính Toán khoảng lặp được dùng trong bài viết để đặc tả các yêu cầu của hệ thống
1 INTRODUCTION The lift control system belongs among real-time control systems The system consists of some physical plant, in permanent interaction with its environment, for which a suitable con- troller has to be constructed such that the controlled plant exhibits the desired time dependent behavior Many authors have proposed approachs for designing the lift control system (e.g [2,10]) However, some approach is just a postulate - it has not yet been widely tested, so a failure in the reaction of the plant may appear The problem is to use suitable technique for specifying and reasoning about the design of the system
For any real-time systems in general, and for our lift control system in particular, the continuous model (real numbers) is suitable for specifying the continuous behavior of the states of the environment and those of the plant, which can change at any time according to the laws of physics However, the state of a digital program changes only at discrete time points
at ticks of a computer clock, so the discrete model (natural numbers) should be considered for implementation of the system Therefore, it is appropriate to combine two models into the same formalism such that the design and its correctness can accurately be reasoned about in
an uniform manner
Using formal methods is a key solution for buiding a correct system In this paper, we apply Duration Calculus with Iteration (DC*), a logic obtained by extending Duration Calculus (DC) (cf e.g [12]) with the iteration operator (*) [1], to model of our lift control system
Trang 2This makes for a logical framework that can handle both continuous time and discrete time models for the system
The design process can be formalised as follows Firstly, a state variables model of the system should be defined The state variables model comprises continuous state variables (modeling the behavior of continuous components) and discrete state variables (modeling the behavior of discrete components) Secondly, the requirement of the system is formalized as
a DC formula Req over continuous state variables A design decision must be established
in order to the requirement of the system will be met and refined into a detailed design Des over continuous state variables such that A - Des = Req, where A stands for some assumptions about the behavior of the environment and the relationship between continuous state variables Finally, the discretization step follows We approximate continuous state variables by discrete ones and formalize the relationship between them based on the general behavior of the sensors and actuators The control requirement is derived from the detailed design and refined into a stmpleDC* formula Cont over discrete state variables such that A, F Cont = Des, where A, stands for some assumptions about the behavior of the environment and the relationship between continuous state variables, and relationship between discrete state variables and continuous ones The discrete formula Cont is the formal specification of the controller
The remaining of the paper is organized as follows In Section 2 we give a brief summary of DC* The discretization technique is peresented in Section 3 Some refinement and verification rules are given in Section 4 The formal design process of the lift control system, the main part of the paper, is contained in Section 5 Section 6 concludes the paper
2 DURATION CALCULUS WITH ITERATION
In this section we give a brief summary of DC* The readers are referred to |1| for more details on the calculus
A language for DC* is built starting from the following sets of symbols: a set of constant symbols {a, b, c, }, a set of individual variables {x, y, z, .},a set of state variables {P,Q, },a set of temporal variables {u, v, .}, a set of function symbols {f, g, }, a set of relation symbols {R,U, }, and a set of temporal propositional letters {A, B, .}
A DC®* language definition is essentially that of the sets of state expressions S, terms t and formulas y of the language These sets can be defined inductively by the following BNFs:
SAO|P|AS|S VS
A
£ = elz|u| ƒ S[( 9)
£ AlR, ,9)|¬e|l(eV ø)|(—£)lte?)|3»e
A state variable P is interpreted as a function [(P): IR — {0,1} (a state) 1(P)Œ) = 1 means that state P is present at time ¢, and [(P)(t) = 0 means that P is not present at time
t We assume that a state has finite variability in any finite time interval A state expression
is interpreted as a function which is defined by the interpretations for the state variables and boolean operators
For an arbitrary state expression S, its duration is denoted by f S Given an interpretation
I of the state variables and an interval, duration f S is interpreted as the accumulated length
Trang 3of time within the interval at which S' is present So for any interval [t, t’], the interpretation
# T(ƒ 5)(£,]) is defined as f I(S)(t)dt
t
A formula ¢ is satisfied by an interpretation in an interval [{¢, t’] when it evaluates to true for that interpretation over that time interval This is written as J, [t,t’] E y
Given an interpretation J, a formula yy’ is true for [¢,t”] if there exists a ¢’ such that
tứ SỨ < and ¢ and ¢’ are true for [¢, ¢’] and [t’, t”], respectively
We consider the following abbreviations:
es fi, [S] A ([S=OHAE> 0), ov Ầ (true yp true), and Oy £ 70-7 We assume that boolean connectives bind more tightly than “~~ Besides, we use some other symbols as abbreviations in the usual way
The proof system for DC* consists of a complete Hilbert-style proof system for first order logic (cf e.g [8]), axioms and rules for interval logic, Duration Calculus axioms and rules and axioms about iteration (cf e.g [12]) We only recall here some axioms and rules of the proof system of DC*
(DC1) fo=0
(DC2) fl=¢
(DC3) fS>0
(DC4) f Si + f S2= [(S1 V S2) + f(S1 A S2)
(DŒã) (ƒS=zxƑ[S=w)> [S5=z+
(DC6) f S$, = f So if S$; © S2 ïn propositional calculus
[6 = 0/Ale ¢ = [A [S]/Aly
[frue/Alw
[£= 0/Al¿ > [[S]“`A/Al¿
[frue/Alw
[true/Aly (DCT) £=0=> ¢*
(DCz) (yg) = ¢
(DCF) (p* Ag" true) > (y' Al = 07 true) V ((e* Any" eg) A ¢') true)
The proof system of DC* is complete for sentences where iteration is allowed only for a restricted class of formulas called simple
Definition 1 Simple DC* formulas are defined inductively by the following BNF
£S £= 0|[S]|a < #|£< al(eV e)|l(@^ @)l(e^£)le!
Trang 4Definition 2 Given a simple DC* formula y, we define a simple DC* formula PRE F(y)
as follows
l PREF({S]) “ [S]*
PREF(¢) V PREF(¢’) PREF()A PREF(@)
gy’) = PREF(¢)V (p- PREF(¢’)) PREF(@*) © g*” PREF(¢)
Intuitively, PRE F(D) is a simple formula that holds for all prefixes of an interval that validates D It follows immediately from the definition that
>< 6
2
3
4
5 PREF
6
7
Proposition 1 ¢ => 7>(=PREF(¢) true)
The class of simple DC* formulas plays an important role in our design process presented
in section 5 The following section presents the discretization technique
3 DISCRETE INTERFACE
A model of real-time control systems is depicted in figure 1 The plant denotes the con- tinuous componets of the system The controller is a discrete component denoting a control program executed by a computer The sensors sample the states of the plant The actu- ators receive commands from the controller and control the plant accordingly The sensors
and the actuators constitute the continuous-to-discrete and discrete-to-continuous interfaces
respectively
disturbances
(environment)
—>
\ Sensors
Figure 1 A model of controlled system
In the following part of this section we defined three concepts for formalising the relation- ship between continuous state variables and discrete ones
Definition 3 (Stability) Given a state variable s and a positive real number 0, we say s is
0 — stable iff the following formula is satisfied by any interval
6 — stable(s) A K([as|[s] [7s] = [as] ([s] A€> 3) `Ƒ[¬S])
The stabelity means that a state should not change quickly in order to be observable at discrete time
Definition 4 (Control state) Given two state variables r and s, and a non-negative real number 0, we say 7 6 — controls s iff the following formula is satisfied by any interval
Trang 5rbss2O([r] Al>6 = (€< 6) fs])
The concept of control state is used for formalising the behaviour of actuators Let r be
a state variable modeling a program command, and s a state of the plant Then the relation
r >g Ss means that whenever the controller issues the command r, the plant gets into state s within at most 6 time units So the maximum response time is 6 time units
Definition 5 (Observation state) Given two state variables r and s, and a non-negative real number 0, we say r 6 — observes s iff the following formula is satisfied by any interval
regs (søz) A (¬s bạ —r) The concept of observation state can be used for formalizing the behavior of the sensors Let r be a state variable modeling a discrete program variable, and s a state of the environment Then the relation r x5 s means that any change (stable enough) in s is observed by the controller within 6 time units So the sampling step is 6 time units Note that the definition say nothing about unstable change of s
We will assume that environment state variables are stable enough to be observable by the controller, otherwise there is no way to observe them in discrete time
For formalising the discrete interface, for any continuous state variable s, we consider a discrete state variable s, used by the control program to observe s via the sensors The relationship between s and its sampling s, is formalised by s, x5 s for some non-negative real number 6 Similarly, for any state ¢ of the plant we consider a command ¢,, a discrete state for requesting (via the actuators) the plant getting into state t The ralationship between ¢ and #¿ is formalised by ¿ by € for some non-negative real number 7
4, REFINEMENT AND VERIFICATION RULES Some rules given in this section are useful for both the refinement and the verification The proofs of some rules and more details are given in [7]
‘Transitivity rules
(7 by 8)(s br È) Rule 2 Œ 2⁄2 5)(s ^z Ÿ)
' P(s+„) Í P(ä1~) 5 Rule 1
These rules say that the accuracy is deteriorated through sequential samplings of a state They are helpful for the design of distributed systems comprising many sensors, as well as how
to use the sensors efficiently
Observation rules
Rule 3
(r #¿ 5) ([zlA£>3)¬^({[¬s]A£>j)=> £<ð~"[r]“`[—r]/ `true Rule 3 allows to capture the change of state from 0 to 1 or from 1 to 0 by observation State Distance
Trang 6Rule 4a (r ^ã 3) 6 — stable(s)
(6 +7) — stable(r) = 7 — stable(s)
(6 +7) — stable(s) > 7 — stable(r)
These rules define a necessary condition for the stability of a continuous state, which is the stability of its sampling and vice-versa It is useful for refinement
State Occurrence
O({t] > é@<7) >O(fs] > €<6+47)
O({r] = é€<7) >O(fs] > €<647) These rules are helpful for both refinement and verification It define how fast the control program should be to satisfy a time constraint about the occurrence of the state
Duration of state
Rule6 PREF([r]* ([ar] ([r] A € > 6))*~ [ar]) = 6 — stable(r)
Rule7 PREF([-r]* (({r] A€ <6)7 [ar])*" ([r] A € < 0)) = Offr] = €< 0)
Invariant Rule for loop
ep => A(true” 7a) €=05>a œ@ > ¬(¬Ø `true) £=0= 8
gt = Ox
Invariant Rule for sequential concatenation
=Llx @>Llx œ Ø>Xx
Rule 9
=> m(Ø `frue) @ => ¬(Wue¬a)
gy = Uy
Trivial parallel composition
Rule 10
A>Lh¿ 8= Ll¿
AAB=[lUAe) Monotonicity
+ <6 Rule lla rer STS° Rule 11b If rz = s then bọ s
rpg s
Rule 11c (reo s)(t Pow) Rule 11d ("9 5 ~o w)
Trang 75 DESIGN A SINGLE LIFT CONTROL SYSTEM
5.1 Problem domain description
The logical control of a lift system studied in this paper consists of a simple, single lift system It allows movement of a single lift cage between a finite number of floors The starting and stopping of the lift [cage] and the opening and closing of floor doors are made by the pressing of floor call, door close and cage send buttons
Components: The lift system has the following immediate components: a lift cage with send buttons, one for each floor; a motor; N +1 floors, each with a floor door, a call button and a close button; sensors and actuators; a controller
We identify floors by natural numbers, numbered 0 to N, and assume that the lift can carry any number of clients!
The system state is made up from the above components with their attributes
Attributes: The system and its components have the following attributes
+ The fift cage is either stopped at floor j for 7 lying between 0 and N inclusive, or is moving
up (or down) between floors 7 and i+ 1 (¢ and i — 1), for ¢ lying between 0 and N —1(N and 1)
+ A floor door is either open or closed
+ The motor is either running up (or down) or is stopped
+ The motor, when running, runs at a constant speed-which causes the lift cage to move between immediately neighbouring floors in f,, time units
Events: We consider only the following events
+ A send button is pressed for floor k, for k = 0, , N
+ A call button on floor k is pressed, for k = 0, , N
+ A close button is pressed for the door at floor k, for k = 0, , N
+ The opening (and closing) of floor doors
+ The starting and stopping of the motor-implying the same for the cage
For the sake of simplicity we do not identify explicitly two journeys of the lift cage: upward one and downward one
Procedure: A lift journey is procedurally described
+ Servicing a floor k means that a send button is pressed for floor k, or a call button on floor
k is pressed, or the lift cage is running upwardly or downwardly (towards floor k)
+ There is a request on floor 7, means that a call or a send button at floor 7 is pressed, iff there does not exist any services of floors and the floor door is closed; or a close button at floor 7 is pressed when the floor door is open This implies that the lift system services floors succesively This dogma makes our design simple
Invariants: The above plus the invariants fully describe expectations
+ There are at least two floors (a component invariant)
+ The cage has exactly one send button for each floor (a component invariant)
+ Pressing a call button at floor ¢ or pressing a send button for floor ¢ causes the lift to service that floor within ¢, time units (a procedural, functional invariant)
Trang 8+ A floor door may only be open if the lift cage is at that floor (a component safety invariant) + The floor door is open for at least fo time units and at most tmax time units (a procedural, functional invariant)
The lift system presented in this paper shall be monitored and controlled by a controller that shall respect the components, handle the events, and satisfy the usual procedures and invariants enumerated above
5.2 Formalizing the requirements of the system
We introduce the following continuous state variables: variable c; holds if the call button
on floor 7 is pressed, variable s; holds if the send button for floor 7 is pressed, variable d; holds
if the door at floor 2 is open, and variable f; holds if the lift is at floor 7, for 2 ranges over interval [0, ,.N]; variable motor hodls if motor is on (and this makes the lift cage move); variable close; holds if the close button on floor 7 is pressed (at the time when the door at: floor 7 is open) We do not model lift positions between floors
The requirements of the system are defined by
Req 4 L(SafetyReq \ Funct Req) The safety property for the lift control system is: for every floor, the door must only be opened if the lift is at that floor This is equivalent to stating that “if the lift is not at floor
2, then door 2 must be closed”
A SafetyReq = |di| = [fil The function requirement is the following conjunction
Funct Req A FL AFLAFS
Pressing a send button causes the lift to service the corresponding floor within ¢, time
ous FA [si] true > €<t,V(E<t, [dj] true)
This requirement states that for every observation interval for which s; hodls initially, ie the send button for the 2/th floor is pressed, either the interval is shorter than or equal to t,
or it may be diveded into three subintervals where the first lasts at most £,, in the second the door at floor 7 is opened, and a final subinterval which is unconstrained
A similar condition must hold when pressing a call button: pressing a call button causes the lift to service the corresponding floor within ¢t, time units
Fy % [es] true + € < t V (6 < te [dj] true)
The system must guarantee that when a floor is serviced, the door is open for at least to time units and at most tax time units
F3 & ([ad;]~ [di]~ [adj] > € > to) A (fdi] > € < tinax) Having defined the requirements, we now present a design decision which implements the requirements
5.3 Design decision
We define the design decision by the predicate Des
Trang 9Des *O(D1A D2 D3A DAA DBA D6A DT)
The following formula is derived directly from the assumptions of the behaviour of the system as described in section 5.1
DỊ Ê((Œ= aA [sị V øï])(É= bÀ ([¬4][4]))
=> (t=a) (LE <bA [Als V GV 5; V c;)]) true) A [>(elose; A ad;)]
A [Cer Adi) A |[—(ø¡ A #¡)| A [908i A di) | A [Alea A dy) A [70 A 65)
A [¬(eœ; A s;)] A [¬(%¡ A s;)] A [¬(%¡ A đ;)]
If for every interval for which a send button for floor 7 is pressed initially, and the lift is at floor 7 and j #7, then the interval may be divided into three subintervals where the first lasts
at most @ time units, in the second the motor is on, and an unconstrained final subinterval; in the condition of 7 = 7, then the door at floor 7 must be opened within @ time units, where 0 stands for a response time of the system A similar condition must hold when pressing a call button at floor ¿
p24 [(s¿ Vœ) A fj] true => (€ < 0)” [motor] true D3 4 (si Veg) A fil true > (€ < 0) [dj] true
If asend button for floor i is pressed while lift is at floor j, the lift may reach the destination floor and then the motor is off and the door at the floor is opened within @ time units A similar condition must hold when pressing a call button at floor 7
pas [(si Ve) A fy] true
) b= |i-altn TE < O [di]) A [fil] true) A [(si V ci) A fi] true
\ré= |i -—glt [( < 8 [>motor]) A [fil] true)
If the close button at floor 7 is pressed it may make the door at the floor open within @ time units
Dã Ê [close;| true => (€ < 0) [nd;| true Two following formulas will help satisfy the requirement of the maximum and minimum time units for which a door is open
p64 [-d;| [d;| true > [rd;| & < to [nclose;| true
Inittially the lift is idle at the ground floor with the doors close, motor stops, and no requests for the lift
Init & [—motør A fo A md; A 7s; \ 7c; A aclose;| true V [|
Trang 10The maximum time it may take to service a floor corresponds to the time it takes to move across N + 1 floors and the response time it takes to open doors
AL (t, > (n+ l)tm + 28)
The following formula is derived directly from the attribute of the motor as described in section 5.1
Ag 4 (sis Vei:)A fj] trues € <0 €=li-glt, [fj] true
We assume that the response time @ is small enough (compare to the speed of the motor) in order to the lift, having reached the destination floor, can be at the floor within at least @ time units while the motor is still running
A3 A4
I¬f#;]“`[; A motor|f `true => [7f;|~ 8 < OA [fi] true
* (ty +041 <tmax) Let A 2 Init \ Al A A2A A3A A4
The following theorem says that the design Des implies the specification Reg, under the assumption A
Theorem 5.3.1 At Des > Req
Proof See Appendix
We will find a discrete specification for the controller as follows
5.4 Discrete design
For any continuous state variable s, let s, be the discrete state variable used by the controller to observe s via the sensors Then the relationships between continuous state vari- ables and discrete state ones are formalised as following formulas: fj ^ã Sis Cie ^ã Ci, dic ^ã
di, Sic x5 $;, and closeje ^ã close;, where 6 is the sampling step
Let Dopen;, Dclose;, Mon, and Moff be discrete state variables, which hold when the controller requests the actuators to open the door at floor 7, close the door at floor 2, start the motor, and stop the motor, respectively The relationship between them and the continuous state variables d; and motor are expressed by Dopen; >, d;, Dclose; >, d;, Monp, motor, and Mof ft,—7motor, where 7 stands for the response time of the plant via the actuators Besides,
we also introduce a symbol £ as one described above, but its value can be calculated only by some computer clock
Let
gl ° ([(Cie V Sie) A fie AM Mon] Ab = 7) (li-Jltm <€< 46+ |i -jltm) [Moff]
£2 = ([(cie V Sic) A fie NM Mon] AL = 7) (li = Jltm << 5 + |i = J ltm)~ [Dopens]
#3 2 ([(Cie V Sic) A fie \ Dopen;| A (= 7)
o1 4 (€> tp — 7) [eloseie A Delose;]
624 (tmax —9-1 << timex — 0)” [Deloses]