A Refinement Calculus for the Development of Real-time Systems
Zhiqiang Chen, Antonio Cau, Hussein Zedan Xiaodong Liu and Hongji Yang Software Technology Research Laboratory De Montfort University
Leicester LE1 9BH, UK g fzqc,cau,zedan,xdl,hjy @dmu.ac.uk
Abstract and mathematical verifications. In the development of real- time systems, formal methods can ensure correctness of We present a calculus which can transfer specifications both functional and temporal requirements. By now, a large to objects for the development of real-time systems. The number of formal methods for the development of real-time object model is based on a practical OO development systems have been put forward, including those based on technique—HRT-HOOD. A real-time logic is specified by logics, (process) algebra, net/graphics or model (for a more extending a sound formal method for real-time systems— detail review, we refer the readers to [3]). TAM, to formalise the object model. With integration of One of underlying formal models of our present work HRT-HOOD and TAM, the advantages of object-oriented is TAM (Temporal Agent Model) [4,5,6,7] which is a re- structured methods with the stepwise refinement techniques alistic formal software development method for real-time are combined. The result is illustrated on a case study. systems. In TAM, the stepwise refinement development method is employed by means of executable constructs to- gether with a specification statement. The TAM theory 1. Introduction views a real-time system as a collection of concurrently exe- cuting agents. These agents communicate via shunts which HRT-HOOD [1] is an object-oriented development tech- are time-stamped with the time of the most recent write. nique that extends the structured methodology HOOD [2] to The TAM real-time logic consists of first order predicate provide objects with both functional and temporal require- logic with a few extensions. A timing function is used to ments of real-time systems. Classification of objects in the represent the value found in variables and shunts at a spe- HRT-HOOD characterises temporal properties of real-time cific time and the projection functions are also used to refer systems. This domain-specific style, with the graphic repre- to the time-stamp and value found in a shunt respectively. sentation and the object description skeleton, makes HRT- Specifications are therefore constraints on the relationship HOOD a concise, cohesive, and powerful set of capabilities. between time-stamps and values found in shunts during the Moreover, HRT-HOOD provides a technique that systemat- lifetime of the system. A mechanism for specifying dura- ically transforms the design to Ada code which presents a tion is provided by the release and termination times of the unifying support to the development of real-time systems. system or agents which may be predicated over in the usual We note that most practical structured and OO software way. TAM has a set of refinement laws which are a set development techniques follow the software engineering of syntactic rewrite rules. These rules enable the software principles that can help developers to avoid errors occur developers to transform a requirement specification into an in the development process (especially at early stages) as executable program. much as possible, but fail to eliminate them completely. We also note that although immense benefits which may However, complete elimination of errors in the development be brought by formal methods, turning them into sound process has been one of the major aims in software engi- practice has proved to be extremely difficult. Some “pure” neering. formal methods may keep practically-oriented software en- Formal methods are believed the most important means gineers from employing their benefits. It has been believed which probably achieve that aim (and others) of software that combining formal methods with practical development engineering with their capabilities of precise descriptions techniques, such as SSADM and OO approaches, can be
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply. a fruitful approach when modelling and developing large- and their executions may be either concurrent or sequen- scaled and complex software systems. On the one hand, by tial. Invocations of methods can be either asynchronous or formalising the constructs of a practical development tech- synchronous. Recursive invocations between methods are nique, formal methods can force the meaning of each sys- prohibited, neither directly nor indirectly. tem component to be more rigorous. On the other hand, An object consists of a declaration and method(s) in a using practical structured and OO techniques with formal structure. The declaration presents the definitions of at- methods can make formal methods more acceptable for use tributes and/or an execution environment for methods de- by a large community. Much work has been undertaken in fined in the object. The attributes of an object include: (1) extending formal notations such as Z and VDM to include object type —WeuseA, S, C, P and Pr to represent, re- the SSADM and OO paradigms, such as [8,9,10]. spectively, that the object is either active, sporadic, cyclic, In this paper, we present the work on combination of a passive, or protected; (2) provided methods —Weuse
practical OO development technique and a formal method
ProvidedMetho ds o to denote the provided method set of
mentioned above by formalising HRT-HOOD [1] with TAM
; an object o. They are declared in the form of m in out , [5] in which a refinement calculus is provided to transform where m is a method name which is free in the object. requirements/specifications to objects for real-time systems in and out are sets which present parameters transfered mathematically. We extended TAM with the capability of between m and its clients; (3) used methods —Weuse
describing behaviours of objects (a computational object
UsedMetho ds o to denote the used method set of an ob-
model) and method invocations. The computational model
ject o. The elements of the set UsedMetho ds o take the
0 0
is defined based on HRT-HOOD, which focuses on speci- 0
form of o ; m ,wherem is a method to be invoked by
fication and may be refined by corresponding HRT-HOOD 0
o and is defined in o . UsedMetho ds o defines use rela-
objects. HRT-HOOD is used to decompose the system’s re-
tionships between o and objects in UsedMetho ds o .Such quirements. Each sub-requirement is formalised, using the relationships specify control flows between objects and to-
TAM specification statement which is subsequently refined
gether with in m and out m , data flows are also specified. into objects by using a set of refinement laws. Other attributes vary with the type of objects: (1) the ac- In the next Section, we introduce the computational ob- tivation interval of the thread for a cyclic object; (2) the ject model and its syntax. A corresponding real-time logic minimum activation interval of the thread for a sporadic ob-
is given briefly in Section 3, which is used to describe ab- ject; (3) the child object set for an active object. We use
stract specification and define the semantics. Based on the ChildObjects o to denote the child object set of o if o is
real-time logic, a refinement calculus is specified in Section an active object. ChildObjects o specifies an include rela- 4. We demonstrate the application of the calculus with a tionship between o and its child objects based on which the case study in Section 5. Some conclusions are presented in decomposition process is achieved; (4) the environment of a the final section. non-active object is a set of data over which the methods of the object execute for computations and communications. 2. Computational Object Model The data include constants, variables and shunts. For cyclic and sporadic objects, an activation period and a minimum
The computational model we used is an extension of that activation interval are specified in the environment declara-
adapted in TAM [5], by introducing objects defined in HRT- tion respectively. We use ObjEnv o to denote the environ- HOOD [1]. In the model, a real-time system is viewed as ment set of an object o. a collection of concurrent activities which are initiated ei- A method consists of a head and a body. The head spec- ther periodically or sporadically with services which can be ifies a method name and a local environment (if necessary) requested by the execution of the activities. The operations of the method. The body specifies operations over either the
of the activities and services, as threads and methods,are object environment or the method environment, or both. We
allocated to the corresponding objects (an encapsulated op- use Metho ds o to denote the set of method defined by the eration environment for the thread or methods) according to object o. their functional and temporal requirements and the relation- The operations are described by means of agents which
ships between them. may be either abstract or concrete. A method can define
Like HRT-HOOD, five types of objects are defined in its local execution environment. We use MthEnv m to de-
6= ;
our model: sporadic objects, cyclic objects, protected ob- note the local environment of the method m.Ifin m
6= ; MthEnv jects, passive objects and active objects. Threads are de- and/or out m , then they are defined in m .A
fined in both sporadic and cyclic objects which activate and method m is defined in the form of
; ] = [MthEnv ] A terminate with the corresponding objects and are concur- m [in out def m end
rent with each other. Methods are defined in protected, pas- where A is an agent, called the body of the method m.We
sive, or active objects, and they are activated by invocations use Am to denote the body of a method m.
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply.
0 0 0
[ ; ]
An active object defines a system or subsystem which 1. o :m in out (Invocation)—o is the name of an 0 consists of a number of related objects as its child ob- object, m0 is the method provided by o and in, out jects, optionally with a number of methods which are im- are optional parameters to be passed to the method
plemented by its child objects. An active object o with m0 as a substitution. This agent causes that an invo-
0 0
;
2 1 1 child objects o 1 , o , ..., o and methods m in out , ..., cation to the method m optionally with in and/or out.
n 1
0
; m in out which are defined in its child objects o , ...,
k k k i1
0 0 0 0 0
[ ; ] : [ ; ] 2. m in out o :m in out (Encapsulation)—o oik can be represented as:
is a child object of the object o and m0 is a method 0
Object o A provided by o . The definition of in, out must be in
0
f g 2
include o1 , o , ..., on accordance with that of m . This agent serves as the
0 0
; f ; g 1 provide m in1 out , ..., m in out 1 k k k
methods body of a method of an active object. It transfers the
0
: ; : ;
1 1 1 1
m in1 out o m in out invocation of m to that of m.
1 i 1 . .
.
0
; : : ; mk ink outk oik mk ink outk end o 3. The Real-Time Logic
A cyclic or sporadic object defines a unique thread that op- Like TAM, a discrete, linear time domain is used which erates periodically or sporadically: is modelled by the natural numbers and denoted by Time. The current time is denoted by the free time variable now Object o C Object o S which is global and can be referred to by any agent. used pair list used pair list period P interval T Variables are used for computation and shared by the constants constant list constants constant list methods within an object or the agents within a method. variables variable list variables variable list shunts shunt list shunts shunt list Their values can be referred to with times. Shunts are used
thread thread for communication with external environments, such as a
A A end o end o sensor in hardware or an object in software. A shunt con- sists of two fields: one holds a (set of) value(s) and another holds a time at which the value(s) is (are) written. Shunts where P and T are the activation period and the minimum are also referred to with times. The difference between vari- activation interval of the corresponding objects. ables and shunts is that shunts are time-stamped. Shunts are Both protected and passive objects are used to define assumed to be non-blocking on reading and writing. An methods which can be requested by other objects. The dif- ference between them is that the methods defined in a pro- event occurrence can be modelled by one or more shunts: tected object can be executed exclusively while those de- it occurs if and only if the shunt is written. To restrict the fined in a passive object can be executed immediately when complexity, we do not classify the domains of values found being requested: in variables and shunts while they are simply defined by Value.
Object o Pr Object o P An invocation is viewed as a special shunt whose value
provide provide and timestamp represent its status and occurrence time. The
; ; :::; ; ; :::; f ; g f ; g
1 1 1 1 1 m1 in out mn inn outn m in out mn inn outn used pair list used pair list invocation status includes: (1) Request—an invocation is constants constant list constants constant list in Request status if and only if it occurs but has not yet variables variable list variables variable list shunts shunt list shunts shunt list been served; (2) Activation—an invocation is in Activation
methods methods status if and only if it has been served, i.e., the requested
; ;
1 1 1 1 1 m1 in out m in out
variables variable list variables variable list method is being executed for it, but has not yet terminated;
A A 1 1 (3) Termination—an invocation is in Termination status if end end . . and only if the execution of the method for it has termi- . .
. . nated.
; ;
mn inn outn mn inn outn A An n We define
end end
InvStatus = fREQ; ACT ; TERg end o end o to represent the domain of the values found in an invocation. Like a shunt, an invocation is assumed to be non-blocking
An agent describes a set of operations with explicit or on reading and writing. We use Inv m to denote the sequence implicit timing constraints. We directly use agents defined of all occurring invocations of a method m. The order of
in [5] in the context of our object model. Two new agents elements in Inv m is that of requests to the method m and an are introduced: element uniquely identifies an invocation. It is assumed that
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply.
an invocation of the method m is put into to Inv m if and only units can be described by the formula:
0 0 0
if it occurs. 0
8 2 [ = 9 2 [ ; +5] = ; ] : ^ :
! 1 ! 2 t t t s ts bt t t t t t t s ts bt t The logic is basically first-order logic with conservative extension to deal with objects, methods and invocations, A predicate can be defined to describe that shunts, vari- ables or constants remain stable during a range of time:
with which temporal and functional requirements of the sys-
8
0 00 0 00
8 2 ; ; 2 [ ; ] = 2 v X t t t1 t v at v at
tem and objects can be described succinctly. >
< if X is a variable set
0 0 !
A free time variable pair t and t is defined to repre-
; ] = ; ] stable ; [ 8 2 ; 2 [ :
2 1 2 1 X t1 t def s X t t t s ts bt t
> if X is a shunt set
sent the activation and termination times of agents, objects : and systems. The activation and termination times of ob- true if X is a constant set jects, methods and agents must be within those of the sys- A shunt is written to exactly once during a range of time tem defining the objects, the objects defining the methods can be specified:
and the method defining the agents respectively. However,
; ] = write sh ; ; [ 2 x s t1 t def
the activation and termination times of threads are viewed
; ] ; ] 9 2 [ = ; ^ stable f g; [ 1] ^ stable f g; [ ;
2 1 2 t t1 t s bt x t s t t s t t as those of the sporadic and cyclic objects which define the
threads respectively. If M is a set of methods provided by a protected object
The timing functions a , b and c are defined over o, then the following predicate must be held for the object
; pairs x t ,wherex is a variable, shunt, or invocation, and o:
t is a time, resulting in the value of the variable, the value
exclusive = 8 ; 2 ; 2 [1; j Inv j]; 2 [1; j Inv j] 2 M def m n M i1 m i n
and the timestamp of the shunt, or an invocation status and
; ] : 9 2 [ Inv
! 1 t t t t m i req ct
its occurrence time at the given time respectively:
: : : = Inv Inv Inv , = ^
2 1 1 2
m i1 act ct n i act ct m i ter ct m n i i
Time ! Value
a : Var
Time ! Value Time
b : Shunts This predicate asserts that executions of all methods in a
S
Inv Time ! InvStatuses Time c : m protected object must be mutually exclusive.
all m Thus specification-oriented semantics of TAM in object
where Var and Shunts are sets of variables and shunts re- context can be derived. We define F is a semantic function,
[[ ]] spectively. such that F X gives the semantics of a component X,such
as an object, method, or agent. For example, if a method
0 Projection functions of b , c for shunts and invocations 0
; invocation o :m in out is used in a method m in an object
are also defined: o,and
: :
2 Ancestor 2 ChildObjects ; 9 ;
2 1
1. v b and ts b result in the value and the timestamp o1 o o o
0 0
2 ProvidedMetho ds = ^ =
2 2 2
of the shunt respectively. m2 o o o m m
: :
r
2. v c and ts c result in an invocation status and its where Ancesto o is the set of ancestors of the object 0
occurrence time respectively. o, and the method m0 is defined as in the object o :
0
; = A end
These functions are used as infix functions. m in out def
time act time
We define that req q , q and then the semantics of the invocation is defined as:
0 0
[[ : ; ]]=
F o m in out
time
ter q represent the request, activation and termi- def
0 0
stable ObjEnv [ MthEnv n ; [ ; ] ^9 2 [ ; ]; 2 [1; j Inv j]
! !
o m out t t t t t i m
0 0 0
nation times of an invocation q to a method m respectively, 0
= REQ; ^9 ; ; Inv ; ^F [[ A[ = = = ; = ]]] ^ !
i ct t t t t t t t t t t in in out out
2 1 2 1 2
m 1
0 0 0
Inv = ; _ Inv 6= ; = = , , !
t ! t out i t t out i and m 2 m
If o C is a cyclic object in the form defined in the last section,
2 [1; j Inv j]; : Time Inv = REQ; 1. 8 i m t m i ct t
then the semantics of o C can be described by:
req Inv =
time m i t
[[ ]]= ChildObjects =;^ ProvidedMetho ds =;^
F o o o
C C
C def
2 [1; j Inv j]; : Time Inv = ACT;
2. 8 i m t m i ct t
0 00 00 0 00 00
2 ; ; 2 UsedMetho ds ; ^ ^ 8 2 Metho ds 6= 6=
o o m o m o o o m m
C C
8 ; ] ; ] 2N; 9 2 [ = 9 2 [
act Inv = ! !
time n t t t t T n t t t
1 2
m i t 1
; ]]] + ^F [[ A[ = = !
t t t T t t t t
1 2 1 1 2
2 [1; j Inv j]; : Time Inv = TER;
3. 8 i m t m i ct t
time Inv = ter m i t 4. Refinement Calculus It is clear that a normal invocation begins with request, activation and then termination. However, in some cases, such as that in passive objects, an invocation starts with ac- The refinement relation v is defined on a component tivation and ends with termination. Moreover, the null oper- (agent, method and object) in a similar fashion to that of
ation in some implementation may have zero duration. This TAM. A component X is refined by the corresponding com-
X vY F [[ Y ]] F [[ X ]] is a useful mechanism, specially in fault-tolerant systems ponent Y ( ) if and only if . in which a fail-stop mechanism is adopted. In such case, a A set of refinement laws are specified, based on the real- request may terminate immediately. time logic specified in the last Section, to transform an abstract specification into concrete objects. Here we give
A sporadic activity in which whenever a shunt s1 is writ-
ten to, another shunt s2 must be written to within 5 time some useful refinement laws.
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply.
Law. 1 (Cyclic object) Law. 6 (Method)
0
2 [0; 1 ; 9 2N; 2 Time = ^
If 8 t n T t T n , then there is 2
Suppose o 1 , o are two objects with the same type.
:v 00
an object o with type of C, such that w o,whereo is in 0
; 9 A 8 2 ProvidedMetho ds 2 ProvidedMetho ds vA
0 00 2 If m o1 m o ,
the form shown as below (left). m m
v : 2 then o1 o
Object o C Object o S Law. 7 (Invocation)
used pair list used pair list 0
; = MthEnv A end
period P interval T If a method m in out def m is de-
0 Bv
constants constant list constants constant list fined in an object o , B is an agent in an object o,and 0
variables variable list variables variable list 0
0
A[ = ; = ] Bv ; in in out out ,then o :m in out and if w w ,
shunts shunt list shunts shunt list B o
0
n B
thread thread then w = w w ,wherew , w and w are frames of , o B
o o B o o
0 0
: :
w w 0
=UsedMetho ds [
end o end o and o respectively, and UsedMetho ds o o
0 0
f ; g o ; m in out
Law. 2 (Sporadic object) Law. 8 (Child Objects)
0 2
Suppose o 1 , o are two active objects.
; ; :::; 8 2 [0; 1 ; 9 2 8 2 [1:: ]; < 2
If t s 1 s sn E , such that i n t t t
0 00 0 00
8 2 ChildObjects 2 ChildObjects v ; 9
1 2 0
0 If o o o o o o ,then
^ : = ^
si :ts bt T si ts bt t , then there is an object o with
v 2
o 1 o v type of S, such that w : o,whereo is in the form shown as above (right). 5. A Case Study
Law. 3 (Passive object)
; = ; = ; ; :::; ; =
1 1 1 2 2 2 2
If m in out def 1 m in out def mn inn outn def n,
W
2 [0; 1 9 : Time stable ; [ ; + ] _ ;
and 8 t d E t t d mi ini outi , In this section we illustrate the formal development of a
[1:: ]
i 2 n real-time system using our model by a case study. The case v then there is an object o with type of P, such that w : o, study is designed based on “The Mine Control System” [1], where o is in the form as shown below (left). as depicted in Fig.1.
Object o P Object o Pr
provide provide
f ; g f ; g ; ; :::; ; ; :::;
1 1 1 1 1 m1 in out mn inn outn m in out mn inn outn used pair list used pair list constants constant list constants constant list Motor Control System variables variable list variables variable list shunts shunt list shunts shunt list
methods methods cmd: {START,STOP} ctrl: {ON,OFF}
; ;
1 1 1 1 1 m1 in out m in out level: N
variables variable list variables variable list
: : 1 w 1 w end end operator_consolegas_sensor motor_interface . . . .
. .
; ;
mn inn outn mn inn outn : w :n w n end end Figure 1: Motor Control System end o end o 5.1. Requirements of the Motor Control System
Law. 4 (Protected object)
; = ; ; = ; :::; ; =
1 1 1 2 2 2 2 If m1 in out def m in out def mn inn outn def n, We can express the system requirements (denoted by REQ)
as:
2 [0; 1 ; 9 : Time
and 8 t d , such that
0
; [ ; + ] _ 8 2 [ ; + ]; 2 [1:: ] ;
stable E t t d t t t d i n mi ini outi at REQ (Motor Control System):
V
; : mj inj outj
Whenever receiving a command from the operator and 10 time units have elapsed
[1:: ]; 6= j 2 n j i since the last command:if the command is “START”, the motor is off, and the gas level is not higher than 40, then the motor is switched on within 5 time units.
if the command is “STOP”, the motor is on, then the motor is switched off within v then there is an object o with type of Pr, such that w : o, 5 time units. Every 20 time units, the gas level is checked, and if the gas level is higher than 40 where o is in the form as shown above (right). and the motor is on, then the motor is switched off within 5 time units.
Law. 5 (Active object) REQ is decomposed into three sub-requirements req , req
1 2 2 If o 1 , o , ..., o , ..., o , ..., o are related objects, then an i1 ik n and req corresponding to gas monitor, operator, and motor
object o can be defined to include them in the form given in respectively:3
v ; ; :::; 2 Section 2, and o 1 o on o.
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply.
req (Operator): 1 Gas Status
spec =def
4
; g :
Whenever a command is received and at least 10 time units have elapsed fgas st s
0 0
since the last: 0
8 [0; 1 : 9 2 [ ; + ] = ^ 9 2 t 2 t t t d s at gasst at t
1. if the command is “START”, the motor is not in operation and the gas 0
; + ] = _
[t t d gas st at s at 5
level is not higher than 40, then switch the motor on within time units.
: Time stable f ; g; [ ; + ]
2. if the command is “STOP” and the motor is in operation, then switch the 9 d gasst s t t d 0
motor off within 5 time units. Correspondingly, spec is adapted, denoted by spec :
2 2
Gas Check 0
spec =def
2
; g :
req (Gas Check): req (Motor): fctrl gas st
2 3
8 [0; 1 9 2N =20 ^
t 2 n t n
> 40 = : :
level v bt ctrl v bt ON
Check the gas level every 20 time Switch the motor on or off if
9 : Time write sh ; ; [ ; ] ^ 5 ^ !
units: d OFF ctrl t t d
= 40
if the level is higher than and requested. Only one operation gas st at SAFE 0
the motor is in operation, then 0
9 : Time + = _
d gas st a t d UNSAFE
switch the motor off within 5 time can be done at the same time.
: 40 ^ =
units. level v bt gas st at UNSAFE
0 0
9 + : Time =
d gas st a t d SAFE
Thus we have
0
= ^ ^
SPEC spec ^ spec spec spec
3 4 def 1
In general, if REQ is inconsistent, then further require- 2 false At this stage, if there is some i, such that spec = ,then ment analysis is needed and if there is some i, such that req i i req must be re-formalised. is not proper, then the decomposition must be redone. i 5.3. Refinement 5.2. Specification of the System
In this Section, we define specifications of the subsys- In this Section, we use refinement laws listed in the Ap- tems and objects to represent corresponding requirements. pendix A to refine sub-specifications derived in the last Sec- This is achieved by identifying the system observables. The tion. At the concrete level, some time parameters are re- system operates the motor according to commands from the moved. operator console and gas level sampled by the gas sensor. We use shunts cmd, level and ctrl to model command, gas
level and motor control interface respectively: 5.3.1 From specifications to Objects
; g
cmd: fSTART STOP The sub-specification spec can be refined by a sporadic ob- 1
level: N
; g ctrl: fON OFF ject Operator (Law. 2) producing:
Sub-specifications spec , spec and spec corresponding to
2 3
req , req and req can1 be specified by means of the real-
2 3 1 Object Operator S time logic: interval 10 shunts
Operator
f ; gTime cmd : START STOP
spec =def
1
f ; g Time
ctrl : ON OFF
g :
fctrl
NTime
level :
8 [0; 1 : 10 ^ t 2 t cmd ts bt
thread
= ; ^ : 40 ^ : =
cmd bt START t level v bt ctrl v bt OFF
g :
fctrl
: Time write sh ; ; [ ; + ] ^ 5 _
9 d ON ctrl t t d d
: = ^ : 40 ^ : =
cmd v bt START level v bt ctrl v bt OFF
= ; ^ : =
cmd bt STOP t ctrl v bt ON
write sh ; ; [ ; ] ^ 5_
! !
ON ctrl t t t t
: Time write sh ; ; [ ; + ] ^ 5
9 d OFF ctrl t t d d
= : ^ : =
cmd v bt STOP ctrl v bt ON
Gas Check
write sh ; ; [ ; ] ^ 5
! ! OFF ctrl t t t t
spec =def
2 end Operator
g :
fctrl
8 [0; 1 9 2N =20 ^ : > 40
t 2 n t n level v bt
= 9 : Time write sh ; ; [ ; + ] ^ 5
ctrl :v bt ON d OFF ctrl t t d d 0
Motor spec can be refined by a cyclic object Gas Check (Law. 1) 2
spec =def
3 producing:
g :
fctrl
2 [0; 1
8 t
: = : write sh ; ; [ ; + ] ^ 5 ^
ctrl v bt1 OFF ON ctrl t t d d
Object Gas Check C
: = write sh ; ; [ ; + ] ^ 5 _
ctrl v bt1 ON OFF ctrl t t d d
period 20
: Time stable ; [ ; + ] 9 d ctrl t t d
shunts
f ; gTime
Because the gas level is also accessed by the object Motor ctrl : ON OFF
NTime level :
to check if the gas is safe, a corresponding method should variables
f ; g be provided. However, because the level is sampled period- gas st : SAFE UNSAFE
ically, it can not be accessed sporadically. We introduce an thread
; g :
fctrl gas st
: > 40 : =
operation Gas Status to maintain a gas status according to level v bt ctrl v bt ON
; ] ^ 9 : Time write sh ; ; [ 5 ^ !
the gas level. A variable is introduced to represent the gas d OFF ctrl t t d
=
gas st at SAFE
0 0
9 : Time = _ +
status: d gas st a t d UNSAFE
: 40 ^ =
level v bt gas st at UNSAFE
f ; g 0
gas st: SAFE UNSAFE 0
: Time + = 9
d gas st a t d SAFE
A corresponding specification spec is defined as: end Gas Check 4
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply. 4. We can encapsulate Gas Check and Gas Status with a new object Gas Monitor which refines them (Law.
spec and spec can be refined by protected objects Motor 4 3 5),showninFig.5. and Gas Status (Law. 4) producing respectively: 5. Operator(Law. 6, Law. 7 and laws on agents), shown in Fig.6. 6. Fig.7 shows the final system.
Object Motor Pr Object Gas Status Pr
; ; ; ; provide set on d set off d provide read s d write s d We omit time obligations because of their observative-
shunts variables ness.
f ; g Time : f ; g ctrl : ON OFF gas st SAFE UNSAFE
methods methods
;
set on d read s d Time
variables d : variables Object Gas Check C Object Operator S
g : : f ; g
fctrl s SAFE UNSAFE used used
; ; ; ;
: = : Time
ctrl v bt OFF d Gas Status write s Gas Monitor check s
; :
write sh ; ; [ g : ; ] ^ f !
ON ctrl t t s Gas Status read s Motor set on
= ^
!
t! t dsat gas st at period 20 interval 10
end t! t d shunts shunts
: NTime : f ; gTime
set off d end level cmd START STOP
Time ;
variables d : write s d variables variables
: N : f ; g
g :
fctrl variables x x START STOP
: Time : Time
: = : f ; g
ctrl v bt ON s SAFE UNSAFE t t
: f ; g : f ; g
write sh ; ; [ : Time ; ] ^ !
OFF ctrl t t d s SAFE UNSAFE s SAFE UNSAFE
f g :
t! t d gas st thread thread
; ;
= ^
end gas st at! s at x t level duration 5
if > 40 then ; ;
end Motor t ! t d x x t cmd
;
end duration d Gas Monitor :check s
; if = ^ = then
end Gas Status Motor :set off x START s SAFE
; :
Gas Status :read s Motor set on
= then orif = then
if s SAFE x STOP
; : Gas Status :write UNSAFE Motor set on endif endif
end endif
rif 40 then o x endif Operator
5.3.2 From Objects to the Final System duration d ;
Motor :set on
;
1. Motor(Law. 6 and laws on agents defined in TAM Gas Status :read s
= then
[5]), shown in Fig.2. if s UNSAFE
; Gas Status :write SAFE 2. Gas Status(Law. 6 and laws on agents), shown in endif Fig.3. end endif end Gas Check
Object Motor Pr Object Gas Status Pr Figure 4: Object Figure 6: Object Operator
;
; g provide set on set off provide fread s write s
shunts variables Gas Check
: f ; g Time
f ; g ctrl ON OFF gas st : SAFE UNSAFE
variables methods
: f ; g
x ON OFF read s
: Time
f ; g t s : SAFE UNSAFE Object Gas Monitor A
methods s := gas st include
set on end Gas Check ; Gas Status
; ;
x t ctrl write s provide check s
if = then
f ; g
x OFF s : SAFE UNSAFE methods
; now !
:=
: : ON ctrl gas st s check s Gas Status read s endif end end Gas Monitor end end Gas Status
set off
; ;
x t ctrl Figure 5: Object Gas Monitor
= then
if x ON
; now ! OFF ctrl endif end end Motor Object Motor Control System A
include ; Figure 2: Object Motor Figure 3: Object Operator ; Gas Monitor Motor Gas Status end Motor Control System
3. Gas Check(Law. 6, Law. 7 andlawsonagents), Figure 7: Design of the System showninFig.4.
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply. 6. Conclusions It is clear that some of the timing characteristics may be left as ‘variables’ to be determined at a later stage of devel- In this paper, we present an approach to integrate a prac- opment. These variables are constraints by the obligations tical OO development technique, HRT-HOOD, and a sound themselves. For example, in the case study presented, the formal method, TAM, in which a refinement calculus is duration and worst case execution time of the operations of provided to transform requirements/specifications to objects concrete thread in the object Gas Check may be left as a for real-time systems. We extended TAM with the capa- variable d which can be determined at the implementation bility of describing behaviours of objects (a computational phase. object model) and method invocations. The computational model is defined based on HRT-HOOD, which focuses on specification and may be refined by corresponding HRT- HOOD objects. HRT-HOOD is used to decompose the sys- Reference tem’s requirements. Each sub-requirement is formalised, using the TAM specification statement which is subsequently refined into objects by using a set of refinement laws. [1]. Burns, A. and Wellings, A., HRT-HOOD: A Struc- With the combination, a framework is specified which tured Design Method for Hard Real-Time Systems, supports the development of real-time systems from infor- Elsevier, 1995. mal requirements to formal specification, concrete design, [2]. European Space Agency, HOOD Reference Manual possibly until executable code. Based on the refinement cal- Issue 3.0, WME/89-353/JB, December 1989. culus, a development method is suggested: [3]. Chen, Z., Formal Methods for Object-Oriented Paradi- 1. Use HRT-HOOD to decompose the system require- gm Applied to the Engineering of Real-Time Sys-
ment, namely REQ, to produce sub-requirements: req 1 , tems: A Review, TechReport, De Montfort Univer-
req 2 , ..., reqn. sity, 1997.
2. Formalise each sub-requirement reqi using the spec- [4]. Scholefield, D. and Zedan, H., TAM: A Formal Frame- 2 ification statement of TAM to produce spec 1 , spec , work for the Development of Distributed Real-Time ..., specn. Note that the formal specification, SPEC, Systems. Symposiums on Formal Techniques in Real- which corresponds to REQ,isgivenby Time and Fault Tolerant Systems, Nijmegen, Nether-
^ lands, January 1992.
SPEC =def speci
[1; ] i2 n [5]. Scholefield, D. and Zedan, H., A Collection of Papers on Temporal Agent Model, FSR Group, University of 3. Use the refinement calculus to refine speci into a con- York, 1993. crete object obj , i.e., i [6]. Scholefield, D., Zedan, H. and He, J., ‘A Specification Oriented Semantics for the Refinement of Real-Time speci v obji Systems’ , Journal of Theoretical Computer Science, 4. The collection of resulting objects are then composed Vol. 129, No. 1, pp. 219-241 (1994). to produce the final concrete system. [7]. Lowe, G. and Zedan, H., ”Refinement of Complex 5. Use HRT-HOOD to map the resulting concrete code Systems: A Case Study”, The Computer Journal, Vol. to an equivalent Ada code. 38, No. 10 (1995). [8]. Lano, K., Distributed System Specification in VDM++, A characteristic of our approach is that during the refine- FORTE’95 Proceedings, Chapman and Hall, 1995. ment stages, all necessary timing information may be gath- ered in the form of ‘proof-obligations’. These obligations [9]. Polack, F., Whiston, M. and Mander, C., The SAZ are obviously proved correct (as a result of the soundness Method, TechReport, YCS207, University of York, of the refinement laws) and are vital to scheduling theo- 1993. rists. Once these obligations are available, various schedul- ing tests and analysis may be applied. In fact these tests [10]. Semmens, L. and Allen, P., Using Yourdon and Z: could also be applied after each refinement step; if the test an Approach to Formal Specification, Proceedings of is not valid then the step is repeated until the obligation is 5th Annual Z User Meeting, Oxford, Springer-Verlag, satisfied. 1991.
Authorized licensed use limited to: Edinburgh Napier University. Downloaded on July 20,2010 at 13:40:22 UTC from IEEE Xplore. Restrictions apply.