- Email: [email protected]
Specification and Design of Reliable Systems in Terms of Unreliable Components
Copyright © IFA C SAFECOMP '85 Como, Italy, 1985
SPECIFICATION AND DESIGN OF RELIABLE SYSTEMS IN TERMS OF UNRELIABLE COMPONENTS
J.
G6rski
Institule of Illfo/"lll atics, T fclil/ica l UI/illersit)' of GdOlisk, Gdallsk, Polalld
Abstract • The paper addresses the problem of designing reliable systems out of unreliable components. The system and its components are specified as modules, using state function temporal logic specifications. Faulty (but tolerable) behaviours are specified by means of spontaneous inputs and nondeterministic post-conditions. G lobal restrictions on possible behaviours are expressed using temporal logic. Individual specifications of modules can be in~orporated by the stucture specification to form the abstract desig n of a hig her level (systeml) module. Keywords • Specification; reliability; desi g n;
faul~tolerance;
temporal log ic.
INTRODUCTION Formal specification technic;ues intend to express requirements on system behaviour. A widely aplied model for system behaviour is the set of sequences that can result from execution. Specification techniques encode requirements on system behaviour in two basic ways: by encoding within the state or by restrictin g possible sequences of states. A variety of speCification approaches can be identified based upon this s~ ate versus history e ncoding (Schwartz, MeliarS mith, 1982). According to this classification at one e nd we have the state machine specifica~ ions where the only description of history allowed is a set of possible successor states from a g iven slate. At the other end are event specifications where the state component simply defines whether a given (possibly param e trize d) event occurs. '!'he specification is a set of predicates on the event history. A duality exists between information encoded in terms of state and in terms of previous history. G iven a set of (possibly infinite) sequences of finite states as an underlying model and a lang uage capabie of expressing arbitrary firs~order properties of sequences, one can eliminate any state information in favor of properties of the history or can transfer any finitely expressible portion of the history to auxiliary state components. In this paper we use a module specification technique which is related to the state transition specification methods, i.e. one specifies a collection of state components and possible state changes that can be caused by the module inputs. However, in our approach we can also express liveness properties and this way impose restrictions on state sequences. The liveness properties are expressed as temporal formulas. Within the spectrum of specification methods considered in (S chwartz, Meliar-Smith, 1982), our method can be placed beside the Lamport's mathod (Lamport., 1983). The useability of our technique is illustrated by specification of the stable storage module. Then we disscuss the problem of faulty behaviours and introduce extensions which allow for specification o f tolerable failures of the module. 'l'his is illustrated by specification of the unreliable storage and the ' 10$ sy transmission line modules. Then the abstract design of a stable storage SCCS -J
in terms of the server and the unreliabl e stora g e modules is pre s e nted which illustrates the possibility of building hi e rarchical specifications.
TEJl. IPORAL LOGIC
Temporal lo gic ( P nueli, 1977) adds operators to the standard lo g ical system to allow r easoning about the futur e properties of computatio ns. A computation is a sc c; u e nc e of states that could aris e during execution, and has the form
5,,-sl,- ' . . Informally, the first state in the computation repre sents the present, and subse q uent states represent the future. T he tw o new operators added to m ak e temporal lo g ic are 0 (henceforth) and (> ( e ventually). Temporal assertions are built up fro m state assertions, usin g the ordinary lo g ical operators and the temporal operators. A state assertion is a boolean valued function of the module (system) state. For a state assertion P , the formula CP means " P is true for ail states in a computation". The formula O P means "the r e is some state in the computation in which P is true". The operators a and <> are duals, and the du-ality is g iven by the tautolo g y -OP=()"'P, which states formally that P is not always true iff it is eventually false. Safety and li veness properties of computations can be expressed using temporal logic. Safety properties can be expressed in terms of a formula of the form [JP or Q ~ OP. A formula of the first form, if stated for a given set of computations, says that every computation continuously satisfies p. In the second form, the formula says that whenever Q is true, P is immediately realized and will hold continuously throughout the rest of the computation. Liveness properties are those expressible by temporal formulas using the 0 operator. For example, () P guarantees the occurrence of a
135
J. G6rski
136
state satisfying p. Q ~ ~p guarantee. that if Q is true at state So then P will be true at some S j • j ~ O. As the final example. consider the assertion 0 (Q ::> p ) • It states that if Q ever becomes true. then P will be true at the same time or later. Such an assertion expresses a liveness property which we pronounce " Q leads, to p ". In the se q uel. it will be abbrevi ated as Q ,.,.,. P •
<>
UNDER LYING MODEL We assume that a system is defined in terms of modules. For each module. a set of inputs and outputs is defined. The system is composed by connecting outputs to inputs among modules. Outputs and inputs are associated with message types. Only outputs and inputs with matching messag e types ar.e allowed to be interconnected. Messag es are created and destroyed in the system. The system state can be observed b y state functions. The following state functions are pre-defined for all systems: enabledOUT (m) - a predicate ; true for a state s iff th e messag e m is c re ated at output OUT. in this state. inlN P (m) - a predicate; true for a state s iff m exists (is processed) in input INP. in this state. atlN P (m) - a predicate; true for a state s iff m arrived at input INP. in this state. afterlNP ( m) - a predicate; true for state s ift it is the first state after m has been destroye d in the input IN P . T he followin g dependencies among cates always hold
these predi-
atlN P(m):> inTNP (m) • afte rIN P (m)";::) 'V InINP ( m ) • if O UT is connected to INP then e nabledOU T ( m) ~ atlNP (m) • The relationship among wn in Fi g. 1.
the predicate s
is sho-
--yo---
at INP (m) Aena bl edOUT( m) L
I NTSH F A C S s e ction sp e cifie s inputs and outputs to ~ ether with th e corresponding m essage do m ains. If -there is no a m bi g uity. it is allowed that an input and the corre sponding output bare the same nrur.e . S TAT E section introduces state functions specific for the module to ce ther w ith their ranges. I N ITIAL define s a s e t of initial conditions (predicate s). Th e sp e cification plac e s constraints only on those state se q uences for which e ach Ij holds for tha initial state so. BEHAVIOUR s e ction d e fin e s a s e t of prope rti p. s i=l, •••• s . E ach prope rty P i C?xpre ss es a cons traint on the entire state se q uenc e Sos , - ·· . The prop e rti e s specifi e d are safe ty prope rti e s and live n e ss prop e rties. A safe ty pro perty asse rt s that somethin g m ust n e v e r happen. It has th e form
r i,
(a)
afte r IN P(m)
inIN P(m)---.J
F ig. 1. The lifespan of a m essace m in the system. m is created in state s. exists throug h states s ••••• s ' and is destroyed in s - . It is assumed that O V'I' is connected to INP.
SPECIFIC;:\TIONS
A
P ARAIVi ETERS section identifies values that are constant for a particular instant of the specified module. DCl\r. AINS section introduces named dorilains of values that are refered to throug hout the specification. Some standard. pre-defined domains like INTSG 2 R. BOOLE AN are inCluded implicitely. New domains can be constructed using domain constructors like SSL) . SET. MAPPIN G, ONEOF. STRUCT . In particular. S El~' (D) denotes the domain of se q uence s of elements of the domain D (including an empty se Cj u e nce <'7). f' or a given seq uence v, vLi] d e notes the i-th element of v. v[i •• j] denotes the subseq u e nce of v composed of e lements vLi] •• vljJ , L ENG TH( v) denotes the num ber of el ~ments in v. The first element of v is always d e noted v (1) • S E T( D) d e notes the domain of all subsets of D . lV' A PPING Dl '1'0 D2 d e notes a set of all total functions from Dl to D 2. ONSOF(Dl, •••• D n) denote s the disjoint '--lnion of domains 0 1 ••••• D n. If deONEOP( D l._ •• Dn) the n IS_D i(d) is tru e iff daDi. STRU CT( nl:Dl •••• ,nm: D m) d e notes the C artesian produc t of domains D l ••••• Dm w ith columns named by nl, •••• nm • S l e ments of this dom ain are denoted (nl~dl •••• ,nmmdm) or (dl ••••• dm ) if there is no ambi g uity with respect to colur.1 n names. NeL is a disting uishe d. sin glE, ton d om ain. ANY stands for any value , the domain resultin g from the context.
module specification has the followin g form:
MODULE modname PARAl\ : ETERS pl:Dl ••••• pn:On DOMAINS dl-Dl. _ • • dn, .Dm INTER FACE INPuTS inpl(ml) ••••• inpk(mk) OUTPU'I'S out1(ml) • • _ • outr(mr) S'l'ATE fl:Dl ••••• fp:Op INITIAL 11. ._ • I q BEHAVIOUR Pl. ••• • Ps
atl N P: PI<'E " PO ST
or
;<.
(b)
I NP: P RS V POST \\'
The inte rpretation is as f o llo ws (lh e unive rsal q uantification ov e r all p o s s ible m e s s a ge s i s assumed)
c,
s uch that atlNP (m) (a) if the r e is a state holds for Cl th e n G must have held for the state r imm e diate ly pre c e ding c: , and r:: must be true for all state s whe re inINI' (m) holds.
(b) if the r e is a state s su.ch that afte rINP ( m ) holds for s thEm V rr. ust hav e h e ld f o r th e state u imm e d i ately pre ceding s, and \ '.' rrust hold for s.
Q is a state pr e dicate referin f': to the state q . R is a state predicate referin g to the states c; and r. \! is a state predicate referin g to the state u. V-I is a state pr e dicate referin g to the states u and s. The refe r e nce to states is by state functions fl .... ,fp • To disting uish betwe en references to differe nt states in R and Vi . references to later s tates are primed. It is also assumed that if a pre-condition is constantly T RU E the n it can be omitted in the specification. Assertions of the form (a) refer to a s late before the message arrives at the input and also they say what condition should be invariant while the message is being process e d by the input. U sually. those re q uire ments can not b e satisfied by the module itself and e xpress SOr.1e
Specification and Design of Reliable Systems constraints imposed on the module's environment. The property of type (b) specify conditions under which a message can be consumed (destroyed) by the input. Note. that the message can be consumed only once and then disappeares forever. Creation of new messages is specified in W by stateing that enabledOUT (m) holds for the state s. This means that a new message m has been created in the state sand cons';Cjuently. atlNP (m) holds for an input INP • if OUT is connected to INP. The relationship of Q.R.V and v; predicates to system state is shown in Fig. 2.
137
OUTPUTS
Deposit() Fetch( d.:Data) STATE store: MAPPING Address TO Data INITIAL FORALL a6Address. storeCa)-ANY BEHAVIOUR 1. atDeposit: POST ' V EXISTS m. inStore( m) 1\ SOURCE (m) aSOURCE 2. Deposit: POST 'store [at] ad 11. enabledDeposit( ;SOURCE) 3. atFetch: POST '" EXISTS m. InStore(m)A SOURCE(m)~ SOURCE 4. Fetch: POST enabledFetch( d-store latl; SOURCE) 5. inDeposit 1\ SOURCEaS ",.,. afterDeposit /\ enabledDeposit(;S)
Q a tI NP
V
~inINPAR~
Fig. 2. Interpretation of the safety specification.
An interconnection between two modules is specified by OUT = . . INP. where OUT and INP can be q ualified by module names to avoid ambiguities (an usual dot notation is assumed here). 'I'he connection can beo one-to-one or one-to-many. If OUT is connecte d to inputs INP1 ••••• INF n • and enabledOUT( m) holds for some state s then aUNPi (m) holds in 5 for exactly one i. i.e. the newly created messa8 e may not arrive at several inputs. To allow for specification of messag e destinations the SOURCE (rr.) state function is defined for each message which returns a name of the module creatin e the message. Also. we modify the " e nabled" predicate to become enabledO U T( m;c) • where c is understood to be a module name and is USQd to choose the destination input ar"on g inputs connected to OUT. If there is no ambi g uity, c can b e omitted. S afety properties assert that something must never happen but they do not require that anythin g does e v er happen. Liveness properties assert what must occur. They are specified using temporal lo g ic assertions. Usually they have the form ~ - . P • which means that for any time at which Go! is true. P must be true then or at some later time.
EXAMPLE: STABLE STORE A s an example let us consider a stable store specification. A pictorial representation of the r.-; odule is g iven in Fig. 3. and the specification is g iven in Fig. 4. DEPOS IT
FETCH
8
Fig. 3. Stable store module.
I'. ;ODULE Store DO!v1 AlNS Address= Data= iNTERFACE INPC TS Deposit( at:Address,d:Data) Fetch ( at:Address)
6. inFetch 1\ SCURCE=S _ afterFetch A enablectFetch( ~;S) Fig. 4. Specification of the module Store. inStore(m):= inDeposit(m)V inFetch(m).
Properties 1 and 3 assert that each user of the m odule must deposit or fetch data one after another, i.e. no concurrent calls from the user are allowed (however. concurrent calls from different users are not excluded). 'I'hese are reqwremen!s imposed on the environment of the module. Property 2 states that if a given Deposit request terminates. the new data d is stored at the address at , and an (empty) response message is created at the Deposit output. directed to the client module. Property 4 asserts that if Fetch terminates then an output l c essar,e with data read from the address at arrives at the Fetch output and is directed to the clie nt module. Any number of modules may be connected to Store. Re c;uests from different modules are served concurrently. Properties 5 and 6 assert that each request will be eventually served. S ~ stands for the unspecified part of the enabled messag e.
SPECIFYING
F AlLUn C
V·.ihen attempting to specify failure. U.e main difficulty encountered is that there is no limit to severity of failure in reality. For instance,while it might be very unlikely. it is possible that all components of the system mi g ht fail at once and break the system beyond repair. There is no system which can survive all possible failures - it will tolerate only certain set of failures. Our approach is to make it explicit which failures will be tolerated • an approach similar to that of (Lampson, 1981). We assume that the intolerable failures can be made as rare as necessary. thus permittin g an arbitrary high (though not perfect) level of reliability to be achieved. Following this line. we divide the possible behaviours of a real system or component 'into acceptable and unacceptable behaviours. VI/e assume that unacceptable behaviours never occur. In practice it means that we assume that the unacceptable behaviours can be made arbitrarily unlikely. The acceptable behaviours are further classified as either good (normal) or bad (failing) but tolerable. Notice. that the notion of tolerability or intolerability is a relative one: behaviours are tolerable or intolerable depending if the environment can or can not handle them. In our approach we assume that failing but tolerable behaviours can be included in the specification. Two basic extensions to our specification technique allow for failure specification.
J. G6rski
138
These are the possibility to use non-deterministic pos~conditions in safety properties of type (b) , and spontaneous inputs which can be included in the specification. The former extension allow to specify failures which can happen in response to a specific input stimulation. 'I'he la~ ter extension is used to specify failures which can happen spontaneously, without strong correlation with the input history. Restrictions on the liveness of the faulty states are specified by temporal logic assertions. While connecting modules to form the system structure, the sponta.neOUS inputs are always left not connected (they specify an internal dynamics of the module). These inputs are considered as being permanently connected to the (invisible) outputs which spontaneously generate messages according to the safety and liveness properties of the module.
EXAJ'y,PLE: UNRELIABLE STORE
The specification of the unreliable store module is given in Fig. 5. MODULE Ustore DOMAINS AddressDataINTERFACE INPUT S U deposit( ad:Address,dt: Data) Ufetch( ad:Address) OUTPUTS Udeposit() Ufetch( OK:BOOLEAN,dt:Data) STATE store:MAPPINC Address TO Data INITIAL FORALL aEAddress, storeLa] -.-'>.NY BEHAVIOUR 1. atUdeposit: POST IV EXISTS m, m~CURRENTJI. inUstore(m)
2. Udeposit: POST EITHER 'store Lad] -dt 1\ enabledUdeposit(; SOURCE) OR 'store (ad] "dt 1\ enabledU deposit(; SOURCE)
tes that if Udeposit is re q uested infinitely often with ad-A and dt-D then eventually D will be stored at A.
EXAMPLE: LOSSY TRANSMISSION LINE
The use of spontaneous inputs is illustrated by a lossy transmission line specification shown in Fig. 6. MODULE Transmission_line PARAr...~ETERS maXD DOMAINS elementa INTERFACE INPU TS Transmit( el:element) Receive( ) OUTPUTS Transmit() Receive( el:element) SPONTANEOUS INPUTS Lose() STATE queue:SEQ (element) INITIAL queueBEHAVIOUR 1. Transmit: PRS LENGTH ( q ueue)< max P OST 'queue-queu e . e I 11. enabledTransmit( ; SOURCE )
2. Receive: PRE LENGTH( queue» 0 POST 'queue-qu e ue i;2 ••LEN G TH ( q ueue )] 1\ enabledReceive (el-q ueue[ 1] ; SOURCE ) 3.Lose: PRE LENGTH ( q ueue» 0 POST \queueaq , WHERE q -( queue
4. inTransmit 1\ SOURC E -SA [JO LENGTH( queue)
< max~afterTransmit(;S)
5. inReceivel\ SOURCE = S JI.[J<)LENGTH(queue) 0afterReceive ( %; S )
>
6. 00 inTransmitACO( atTransmit::::> Transmit.el-E ) 1\0<> inReceive ,.,.. afterR eceiveA enabled l~eceive ( el-E; 7~ )
Fi£_ 6. Specification of the Transmission_line module.
3. atUfetch: POST - EXISTS m, mol< CURRENT/\ inUstore(m)
4. Ufetch: POST EITHER enabledUfetch( OKmTRUE,dt=store [ad] ,SOURCE) OR enabledUfetch( 0 K-FALSE,dtaANY, SOURCE)
The specification g iven in Fig. 6. specifies a lossy one-way transmission medium. Up to max data elements can be currently during transmission. Elements are inserted throug h tht Transmit input. In order to receive e lements, the Receive input has to be activated. Losing of elements in-tramsmission is specified by introducing the
5. inUdepositA SOURCEaS -afterUdeposit(;S) 6. inUfetch /\ SOURCE-S -afterUfetch( 7~;S) 7. 8.
0<>( atUfetch 1\ Ufetch,ad-A)\ SOU R CE-S )_afterU fetch/\ enabledUfetch( OK -TRUE
0<>( atUdepositl\
I
dt=store[AJ;S)
Udeposit.ad=A A Udeposit.dt-D A SOURCE-S )~after U deposit(;S) 1\ store [A]
Fig. 5. Specification of the U store module.
Properties 1,3 assert that the module is used serially (CURRENT refers to the message bound by the universal quantifier over all messages, implicitely assumed for each property). Property 2 specifies that Udeposit can corrupt data stored at the address ad. Similarly, property 4 states that Ufetch, if completed, returns either OK-TRUE together with data stored at the address ad, or OK-FALSE together with any data. Properties 5,6,7,8 are liveness properties. Properties 5,6 specify that Udeposit and Ufetch input messages must be eventually processed. Property 7 asserts that if Ufetch is requested infinitely often with ad-D then eventually an ou~ put message will be returned with uncorrupted data read from the address A. Property 8 sta.-
=!)
SPONTANEOUS INPUTS section which defines the input Lose. Lose g enerates messages spontaneously. It can force losing of elements each lime the queue is nonempty (-< in property 3 means "is a proper subsequence of"). Property 4 asserts that the processing of the Transmit request messages is fair, in the sense that if queue is infinitely often nonful then the request is eventually served and the messag e is put at the end of the queue. Similarly, property 5 states that the Receive request messages will be processed if the queue is infinitely often nonempty. Property 6 states that if a given element E is transmitted infinitely often and there are still attempts to receive elements then E is eventually received.
Specification and Design of Reliable Systems
l.)ESIGNING A
STABLE STORE
.!.\formal design oC a system is given by its stT'ucture specification. The constructs that describe the design are the system specification, the subsysterps specifications, the subsystems interconnection specification and the interlace specification. The system and subsystems specifications are given as module specifications, in the Corm introduced in the previous sections. The subsystem interconnection specification connects outputs to inputs among sUbsystems. The construct Sl.0LiT-.52.INP speciCies that the output OUT of Sl is connected to the input INP of S2. Then, if enabled01.JT( m; S2) holds Cor a g iven state s then aUNP (m) also holds for s. The interlace specification, given in the Corm SYS.INPi -
S1.JB.INF-j
139
6. Uread: POST IF IS_PendingW( serve) /\ OK THEN IF serve.dal-dt THEN IS _NIL('serve ) J\ enabledWrite (; server. who) ELSE enabledUwrite( ad-server.to,dt-server.dat) IF
rvOK THEN IF IS_Pending'V'l ( serve) THEN enabledUwrite ( ad~server. td,dt-server.dat) ELSE enabledUread( ad-server.from)
IF IS_PendingR(serve) J\ OK THEN IS_NIL ( serve) /\ enabledRead ( d-dt; server. who)
7. atUwrite: POST
IS_PendingW (serve)
<.l. Uwrite: POST enabledUread( ad-serve. to)
9. inUwrite -afterUwrite 10. inUread_sfterUread 11. inWrite" Write.d-D A Vv rite.at-A /\ SOURCE-S A C()IS_NIL( serve )rv...afterWrite J\ serve=(A,D,S)
or SYS.OLiTi -
SUB.OUTj
specifies that the input INPj of the subsystem SUB is used as the input INl'-'i oC th e system SYS , or that the output 01.JTj oC SUB is used as th e output OUTi of SYS. In this section we speciCy the n:odule Server and then d e fine 0. s tructur e which is the Corrllal desi g n (in terms oC subsystems Server and C store) of the stable store system specified by the module Store. The specification of the Server ['1o dule is c iven in Fig. 7. l'v:ODC;L E Server DOl'..;AINS ,) o.to.= Addr ess t ' endin g'vV =STHUC T( to:Address,dat:Data, who:I\ ': odnam e ) j ' endingR =ST 1<1.JCT (from:Address,who: l\,)odname)
12. inxead/\ React.at-A/\ S OUR CE.SA O()IS_NIL( serve)~afterReadA serve=(A,S) Fig. 7. Specification oC the Server module.
The meanin g oC the speciCication is as follows. Processing of a vVrite request sets the serve state component according to the parameters oC the request message and then repeat U write followed by U read until the Urcad response confirms that the data were stored correcUy (OKaTRUE ). Processing oC a Read re q uest sets the serve state component according to the requestin g message and then repeats Uread requests generated at the Uread output until receivin g an uncorrupted data (OK= TRUE ). The liveness properties 9,10,11,12 speciCy conditions under which the input message s oC Server ar e eventually proc e ssed. Formal desig n oC the stable storage system is shown in Fig. El.
IN'l'ERF/\C~
IN!·'I;TS V/ rite( at:Address,d:Dato.) r<. eact ( at:Address) 1.Jv:rite ( ) 1.J read( OK :DOOLE,c,,'\l,dt:Do.ta) OUTP UT S Write( ) I
SYSTEM
Storage
SUBSYSTEJ\-~ S
S erver, U store
CONNECTIONS Server.t:write-,. t.'store.Udeposit Server.Uread-_ Ustore.Ufetch Ustore.Udeposit~_ Server.Uwrite U store.UCetch-. Server.Uread
ST ATE serve:ONEOF ( ! 1 en ding'.V , Pe ndingx,N IL ) I:-:ITLll.L IS_NIL( serve ) BEHAVI 01.Jr< 1. atWrite: F OST ' " EXISTS m, n: ;i6 CUR r~ENTJ\ inServer(m) /\ SOURCE(m)SOCRCS 2. Wri t e : lORE IS_NIL( serve) ! j OST 's erve ~( at,d,SOURCE ) " enabledUwrite( ad-at, dt-d) 3.atRead: POST ' " EXISTS m, m;16 C1.JR RENT/\ inServer(m)" SOURCE(m)SOt.;l'<.CE 4. i
INTERFACE INPUTS Store.Deposit - Server. Write Store.Fetch = Server.Read OUTPUTS Store.geposit - Server. W rite Store.Fetch - Server.Read
J. G6rski
140
- Y§.Tf..H ___ ,
DEPOS IT r - - --I
STORE
I
I
I I
READ
WRITE SE RVER
UREAD
UWRITE UDEPOS IT
UFETC H
,........IikU-----z..L....;
I
USTORE
I L ___ _
F i g. o . Formal desi g n
of th e stable storag e.
CON C L t.: S I ONS
We hav e pres e ntl! d a me thod of m odule sp e cifica tion which allows for -
sp e cification of bo th, s afe ty and liven e ss prop e rties of the m odule , s p e cification of modules that are u se d concurrently, sp e cification of tol e rable failures, s truc tural sp e cification.
l'v: odul e sp e cification d es cribe s its possibl e behav iours by g ivinr, a s e t of properties which have to be satisfi e d by e ach individual b e h~ v iour (a hi s tory of states ). The properties impos e r e s t ricti o ns e ith e r o n the possible state tran s itions r e sultin c fro m th e m odul e 's inte ract.ion w ith th e e nvironment, or o n t h e w hole histori e s of s tates. Th e safe ty proper ti<~ s can includ e as s u m ptions about th e e nvironment of th e mo dul e , e. g. prop erti es 1,3 in th e specification of S tore . In particular, thes e assum ptions can restrict the amount of concurre ncy exercis e d w ith respect to th e module . S pontaneous inputs and nondete rministic post.c onditions allow for sp e cification of faulty b e haviours which can d l? p e nd on or be indep e nd e n t of thl? specific input stimulation. The corr e spondin g live n e ss pro pe rti e s restrict the occurr e nc e of faults in s tate histori e s and thi s way provide a g uarantee that th e c orr e ct behaviours ar e achiev abl l? , at l e ast to the e xtend which allow to tol e rate failur e s at th e hig her (system ) l evel. S tructural s p e cification s co m bine modul e sp e cifications into a form al d e si g n and link the d e si g n to th e hi g her l evel (syste m) specification. This is this system l e vel whe r e the lower level failures are tolerate d. This has been illustrated by a formal desi g n of the stable storage system. Evide ntly, a verification step is necessary to demonstrate that the desig n satisfies the specification of th e Store module. Such a verification would re q uire a d e finition of the state functions of Store in terms of the state functions o f U store and S erve r and then we would have to show that th e properties of the subsystems do not invalidate the properties speCified for the whole system. S uch a verification techni q ue is currently unde r deve lopment.
REFERENCES
Lamport L. (1983). Specifying Concurrent Program Modules. ACM Trans. P rogram. Lang. Systems, vol. 5, No. 2, 190-222. Lampson B. (1981). Atomic Transactions. In Distributed Systems: Architecture and Implementation, Lect. Not. Comp.· Sci., No. 105, 246-265. P nueH A. (1977). The Temporal Logic ~ Prog~. Proc. 1 8 th Symp. Foundations of Computer SCience, IEE E, Providence, 46-57. Schwartz L.R. and p. 1\·1 eHar-Smith. (1982). £.!:2!!!.. ~ Machines E Temporal Logic: Specification M e thods !2!' P rotocol Stan~. IEE E Trans. Comm., vol. CO M-30, N o. 12, 24 8 6-2496.
SPECIFICATION AND DESIGN OF RELIABLE SYSTEMS IN TERMS OF UNRELIABLE COMPONENTS
J.
G6rski
Institule of Illfo/"lll atics, T fclil/ica l UI/illersit)' of GdOlisk, Gdallsk, Polalld
Abstract • The paper addresses the problem of designing reliable systems out of unreliable components. The system and its components are specified as modules, using state function temporal logic specifications. Faulty (but tolerable) behaviours are specified by means of spontaneous inputs and nondeterministic post-conditions. G lobal restrictions on possible behaviours are expressed using temporal logic. Individual specifications of modules can be in~orporated by the stucture specification to form the abstract desig n of a hig her level (systeml) module. Keywords • Specification; reliability; desi g n;
faul~tolerance;
temporal log ic.
INTRODUCTION Formal specification technic;ues intend to express requirements on system behaviour. A widely aplied model for system behaviour is the set of sequences that can result from execution. Specification techniques encode requirements on system behaviour in two basic ways: by encoding within the state or by restrictin g possible sequences of states. A variety of speCification approaches can be identified based upon this s~ ate versus history e ncoding (Schwartz, MeliarS mith, 1982). According to this classification at one e nd we have the state machine specifica~ ions where the only description of history allowed is a set of possible successor states from a g iven slate. At the other end are event specifications where the state component simply defines whether a given (possibly param e trize d) event occurs. '!'he specification is a set of predicates on the event history. A duality exists between information encoded in terms of state and in terms of previous history. G iven a set of (possibly infinite) sequences of finite states as an underlying model and a lang uage capabie of expressing arbitrary firs~order properties of sequences, one can eliminate any state information in favor of properties of the history or can transfer any finitely expressible portion of the history to auxiliary state components. In this paper we use a module specification technique which is related to the state transition specification methods, i.e. one specifies a collection of state components and possible state changes that can be caused by the module inputs. However, in our approach we can also express liveness properties and this way impose restrictions on state sequences. The liveness properties are expressed as temporal formulas. Within the spectrum of specification methods considered in (S chwartz, Meliar-Smith, 1982), our method can be placed beside the Lamport's mathod (Lamport., 1983). The useability of our technique is illustrated by specification of the stable storage module. Then we disscuss the problem of faulty behaviours and introduce extensions which allow for specification o f tolerable failures of the module. 'l'his is illustrated by specification of the unreliable storage and the ' 10$ sy transmission line modules. Then the abstract design of a stable storage SCCS -J
in terms of the server and the unreliabl e stora g e modules is pre s e nted which illustrates the possibility of building hi e rarchical specifications.
TEJl. IPORAL LOGIC
Temporal lo gic ( P nueli, 1977) adds operators to the standard lo g ical system to allow r easoning about the futur e properties of computatio ns. A computation is a sc c; u e nc e of states that could aris e during execution, and has the form
5,,-sl,- ' . . Informally, the first state in the computation repre sents the present, and subse q uent states represent the future. T he tw o new operators added to m ak e temporal lo g ic are 0 (henceforth) and (> ( e ventually). Temporal assertions are built up fro m state assertions, usin g the ordinary lo g ical operators and the temporal operators. A state assertion is a boolean valued function of the module (system) state. For a state assertion P , the formula CP means " P is true for ail states in a computation". The formula O P means "the r e is some state in the computation in which P is true". The operators a and <> are duals, and the du-ality is g iven by the tautolo g y -OP=()"'P, which states formally that P is not always true iff it is eventually false. Safety and li veness properties of computations can be expressed using temporal logic. Safety properties can be expressed in terms of a formula of the form [JP or Q ~ OP. A formula of the first form, if stated for a given set of computations, says that every computation continuously satisfies p. In the second form, the formula says that whenever Q is true, P is immediately realized and will hold continuously throughout the rest of the computation. Liveness properties are those expressible by temporal formulas using the 0 operator. For example, () P guarantees the occurrence of a
135
J. G6rski
136
state satisfying p. Q ~ ~p guarantee. that if Q is true at state So then P will be true at some S j • j ~ O. As the final example. consider the assertion 0 (Q ::> p ) • It states that if Q ever becomes true. then P will be true at the same time or later. Such an assertion expresses a liveness property which we pronounce " Q leads, to p ". In the se q uel. it will be abbrevi ated as Q ,.,.,. P •
<>
UNDER LYING MODEL We assume that a system is defined in terms of modules. For each module. a set of inputs and outputs is defined. The system is composed by connecting outputs to inputs among modules. Outputs and inputs are associated with message types. Only outputs and inputs with matching messag e types ar.e allowed to be interconnected. Messag es are created and destroyed in the system. The system state can be observed b y state functions. The following state functions are pre-defined for all systems: enabledOUT (m) - a predicate ; true for a state s iff th e messag e m is c re ated at output OUT. in this state. inlN P (m) - a predicate; true for a state s iff m exists (is processed) in input INP. in this state. atlN P (m) - a predicate; true for a state s iff m arrived at input INP. in this state. afterlNP ( m) - a predicate; true for state s ift it is the first state after m has been destroye d in the input IN P . T he followin g dependencies among cates always hold
these predi-
atlN P(m):> inTNP (m) • afte rIN P (m)";::) 'V InINP ( m ) • if O UT is connected to INP then e nabledOU T ( m) ~ atlNP (m) • The relationship among wn in Fi g. 1.
the predicate s
is sho-
--yo---
at INP (m) Aena bl edOUT( m) L
I NTSH F A C S s e ction sp e cifie s inputs and outputs to ~ ether with th e corresponding m essage do m ains. If -there is no a m bi g uity. it is allowed that an input and the corre sponding output bare the same nrur.e . S TAT E section introduces state functions specific for the module to ce ther w ith their ranges. I N ITIAL define s a s e t of initial conditions (predicate s). Th e sp e cification plac e s constraints only on those state se q uences for which e ach Ij holds for tha initial state so. BEHAVIOUR s e ction d e fin e s a s e t of prope rti p. s i=l, •••• s . E ach prope rty P i C?xpre ss es a cons traint on the entire state se q uenc e Sos , - ·· . The prop e rti e s specifi e d are safe ty prope rti e s and live n e ss prop e rties. A safe ty pro perty asse rt s that somethin g m ust n e v e r happen. It has th e form
r i,
(a)
afte r IN P(m)
inIN P(m)---.J
F ig. 1. The lifespan of a m essace m in the system. m is created in state s. exists throug h states s ••••• s ' and is destroyed in s - . It is assumed that O V'I' is connected to INP.
SPECIFIC;:\TIONS
A
P ARAIVi ETERS section identifies values that are constant for a particular instant of the specified module. DCl\r. AINS section introduces named dorilains of values that are refered to throug hout the specification. Some standard. pre-defined domains like INTSG 2 R. BOOLE AN are inCluded implicitely. New domains can be constructed using domain constructors like SSL) . SET. MAPPIN G, ONEOF. STRUCT . In particular. S El~' (D) denotes the domain of se q uence s of elements of the domain D (including an empty se Cj u e nce <'7). f' or a given seq uence v, vLi] d e notes the i-th element of v. v[i •• j] denotes the subseq u e nce of v composed of e lements vLi] •• vljJ , L ENG TH( v) denotes the num ber of el ~ments in v. The first element of v is always d e noted v (1) • S E T( D) d e notes the domain of all subsets of D . lV' A PPING Dl '1'0 D2 d e notes a set of all total functions from Dl to D 2. ONSOF(Dl, •••• D n) denote s the disjoint '--lnion of domains 0 1 ••••• D n. If deONEOP( D l._ •• Dn) the n IS_D i(d) is tru e iff daDi. STRU CT( nl:Dl •••• ,nm: D m) d e notes the C artesian produc t of domains D l ••••• Dm w ith columns named by nl, •••• nm • S l e ments of this dom ain are denoted (nl~dl •••• ,nmmdm) or (dl ••••• dm ) if there is no ambi g uity with respect to colur.1 n names. NeL is a disting uishe d. sin glE, ton d om ain. ANY stands for any value , the domain resultin g from the context.
module specification has the followin g form:
MODULE modname PARAl\ : ETERS pl:Dl ••••• pn:On DOMAINS dl-Dl. _ • • dn, .Dm INTER FACE INPuTS inpl(ml) ••••• inpk(mk) OUTPU'I'S out1(ml) • • _ • outr(mr) S'l'ATE fl:Dl ••••• fp:Op INITIAL 11. ._ • I q BEHAVIOUR Pl. ••• • Ps
atl N P: PI<'E " PO ST
or
;<.
(b)
I NP: P RS V POST \\'
The inte rpretation is as f o llo ws (lh e unive rsal q uantification ov e r all p o s s ible m e s s a ge s i s assumed)
c,
s uch that atlNP (m) (a) if the r e is a state holds for Cl th e n G must have held for the state r imm e diate ly pre c e ding c: , and r:: must be true for all state s whe re inINI' (m) holds.
(b) if the r e is a state s su.ch that afte rINP ( m ) holds for s thEm V rr. ust hav e h e ld f o r th e state u imm e d i ately pre ceding s, and \ '.' rrust hold for s.
Q is a state pr e dicate referin f': to the state q . R is a state predicate referin g to the states c; and r. \! is a state predicate referin g to the state u. V-I is a state pr e dicate referin g to the states u and s. The refe r e nce to states is by state functions fl .... ,fp • To disting uish betwe en references to differe nt states in R and Vi . references to later s tates are primed. It is also assumed that if a pre-condition is constantly T RU E the n it can be omitted in the specification. Assertions of the form (a) refer to a s late before the message arrives at the input and also they say what condition should be invariant while the message is being process e d by the input. U sually. those re q uire ments can not b e satisfied by the module itself and e xpress SOr.1e
Specification and Design of Reliable Systems constraints imposed on the module's environment. The property of type (b) specify conditions under which a message can be consumed (destroyed) by the input. Note. that the message can be consumed only once and then disappeares forever. Creation of new messages is specified in W by stateing that enabledOUT (m) holds for the state s. This means that a new message m has been created in the state sand cons';Cjuently. atlNP (m) holds for an input INP • if OUT is connected to INP. The relationship of Q.R.V and v; predicates to system state is shown in Fig. 2.
137
OUTPUTS
Deposit() Fetch( d.:Data) STATE store: MAPPING Address TO Data INITIAL FORALL a6Address. storeCa)-ANY BEHAVIOUR 1. atDeposit: POST ' V EXISTS m. inStore( m) 1\ SOURCE (m) aSOURCE 2. Deposit: POST 'store [at] ad 11. enabledDeposit( ;SOURCE) 3. atFetch: POST '" EXISTS m. InStore(m)A SOURCE(m)~ SOURCE 4. Fetch: POST enabledFetch( d-store latl; SOURCE) 5. inDeposit 1\ SOURCEaS ",.,. afterDeposit /\ enabledDeposit(;S)
Q a tI NP
V
~inINPAR~
Fig. 2. Interpretation of the safety specification.
An interconnection between two modules is specified by OUT = . . INP. where OUT and INP can be q ualified by module names to avoid ambiguities (an usual dot notation is assumed here). 'I'he connection can beo one-to-one or one-to-many. If OUT is connecte d to inputs INP1 ••••• INF n • and enabledOUT( m) holds for some state s then aUNPi (m) holds in 5 for exactly one i. i.e. the newly created messa8 e may not arrive at several inputs. To allow for specification of messag e destinations the SOURCE (rr.) state function is defined for each message which returns a name of the module creatin e the message. Also. we modify the " e nabled" predicate to become enabledO U T( m;c) • where c is understood to be a module name and is USQd to choose the destination input ar"on g inputs connected to OUT. If there is no ambi g uity, c can b e omitted. S afety properties assert that something must never happen but they do not require that anythin g does e v er happen. Liveness properties assert what must occur. They are specified using temporal lo g ic assertions. Usually they have the form ~ - . P • which means that for any time at which Go! is true. P must be true then or at some later time.
EXAMPLE: STABLE STORE A s an example let us consider a stable store specification. A pictorial representation of the r.-; odule is g iven in Fig. 3. and the specification is g iven in Fig. 4. DEPOS IT
FETCH
8
Fig. 3. Stable store module.
I'. ;ODULE Store DO!v1 AlNS Address= Data= iNTERFACE INPC TS Deposit( at:Address,d:Data) Fetch ( at:Address)
6. inFetch 1\ SCURCE=S _ afterFetch A enablectFetch( ~;S) Fig. 4. Specification of the module Store. inStore(m):= inDeposit(m)V inFetch(m).
Properties 1 and 3 assert that each user of the m odule must deposit or fetch data one after another, i.e. no concurrent calls from the user are allowed (however. concurrent calls from different users are not excluded). 'I'hese are reqwremen!s imposed on the environment of the module. Property 2 states that if a given Deposit request terminates. the new data d is stored at the address at , and an (empty) response message is created at the Deposit output. directed to the client module. Property 4 asserts that if Fetch terminates then an output l c essar,e with data read from the address at arrives at the Fetch output and is directed to the clie nt module. Any number of modules may be connected to Store. Re c;uests from different modules are served concurrently. Properties 5 and 6 assert that each request will be eventually served. S ~ stands for the unspecified part of the enabled messag e.
SPECIFYING
F AlLUn C
V·.ihen attempting to specify failure. U.e main difficulty encountered is that there is no limit to severity of failure in reality. For instance,while it might be very unlikely. it is possible that all components of the system mi g ht fail at once and break the system beyond repair. There is no system which can survive all possible failures - it will tolerate only certain set of failures. Our approach is to make it explicit which failures will be tolerated • an approach similar to that of (Lampson, 1981). We assume that the intolerable failures can be made as rare as necessary. thus permittin g an arbitrary high (though not perfect) level of reliability to be achieved. Following this line. we divide the possible behaviours of a real system or component 'into acceptable and unacceptable behaviours. VI/e assume that unacceptable behaviours never occur. In practice it means that we assume that the unacceptable behaviours can be made arbitrarily unlikely. The acceptable behaviours are further classified as either good (normal) or bad (failing) but tolerable. Notice. that the notion of tolerability or intolerability is a relative one: behaviours are tolerable or intolerable depending if the environment can or can not handle them. In our approach we assume that failing but tolerable behaviours can be included in the specification. Two basic extensions to our specification technique allow for failure specification.
J. G6rski
138
These are the possibility to use non-deterministic pos~conditions in safety properties of type (b) , and spontaneous inputs which can be included in the specification. The former extension allow to specify failures which can happen in response to a specific input stimulation. 'I'he la~ ter extension is used to specify failures which can happen spontaneously, without strong correlation with the input history. Restrictions on the liveness of the faulty states are specified by temporal logic assertions. While connecting modules to form the system structure, the sponta.neOUS inputs are always left not connected (they specify an internal dynamics of the module). These inputs are considered as being permanently connected to the (invisible) outputs which spontaneously generate messages according to the safety and liveness properties of the module.
EXAJ'y,PLE: UNRELIABLE STORE
The specification of the unreliable store module is given in Fig. 5. MODULE Ustore DOMAINS AddressDataINTERFACE INPUT S U deposit( ad:Address,dt: Data) Ufetch( ad:Address) OUTPUTS Udeposit() Ufetch( OK:BOOLEAN,dt:Data) STATE store:MAPPINC Address TO Data INITIAL FORALL aEAddress, storeLa] -.-'>.NY BEHAVIOUR 1. atUdeposit: POST IV EXISTS m, m~CURRENTJI. inUstore(m)
2. Udeposit: POST EITHER 'store Lad] -dt 1\ enabledUdeposit(; SOURCE) OR 'store (ad] "dt 1\ enabledU deposit(; SOURCE)
tes that if Udeposit is re q uested infinitely often with ad-A and dt-D then eventually D will be stored at A.
EXAMPLE: LOSSY TRANSMISSION LINE
The use of spontaneous inputs is illustrated by a lossy transmission line specification shown in Fig. 6. MODULE Transmission_line PARAr...~ETERS maXD DOMAINS elementa INTERFACE INPU TS Transmit( el:element) Receive( ) OUTPUTS Transmit() Receive( el:element) SPONTANEOUS INPUTS Lose() STATE queue:SEQ (element) INITIAL queueBEHAVIOUR 1. Transmit: PRS LENGTH ( q ueue)< max P OST 'queue-queu e . e I 11. enabledTransmit( ; SOURCE )
2. Receive: PRE LENGTH( queue» 0 POST 'queue-qu e ue i;2 ••LEN G TH ( q ueue )] 1\ enabledReceive (el-q ueue[ 1] ; SOURCE ) 3.Lose: PRE LENGTH ( q ueue» 0 POST \queueaq , WHERE q -( queue
4. inTransmit 1\ SOURC E -SA [JO LENGTH( queue)
< max~afterTransmit(;S)
5. inReceivel\ SOURCE = S JI.[J<)LENGTH(queue) 0afterReceive ( %; S )
>
6. 00 inTransmitACO( atTransmit::::> Transmit.el-E ) 1\0<> inReceive ,.,.. afterR eceiveA enabled l~eceive ( el-E; 7~ )
Fi£_ 6. Specification of the Transmission_line module.
3. atUfetch: POST - EXISTS m, mol< CURRENT/\ inUstore(m)
4. Ufetch: POST EITHER enabledUfetch( OKmTRUE,dt=store [ad] ,SOURCE) OR enabledUfetch( 0 K-FALSE,dtaANY, SOURCE)
The specification g iven in Fig. 6. specifies a lossy one-way transmission medium. Up to max data elements can be currently during transmission. Elements are inserted throug h tht Transmit input. In order to receive e lements, the Receive input has to be activated. Losing of elements in-tramsmission is specified by introducing the
5. inUdepositA SOURCEaS -afterUdeposit(;S) 6. inUfetch /\ SOURCE-S -afterUfetch( 7~;S) 7. 8.
0<>( atUfetch 1\ Ufetch,ad-A)\ SOU R CE-S )_afterU fetch/\ enabledUfetch( OK -TRUE
0<>( atUdepositl\
I
dt=store[AJ;S)
Udeposit.ad=A A Udeposit.dt-D A SOURCE-S )~after U deposit(;S) 1\ store [A]
Fig. 5. Specification of the U store module.
Properties 1,3 assert that the module is used serially (CURRENT refers to the message bound by the universal quantifier over all messages, implicitely assumed for each property). Property 2 specifies that Udeposit can corrupt data stored at the address ad. Similarly, property 4 states that Ufetch, if completed, returns either OK-TRUE together with data stored at the address ad, or OK-FALSE together with any data. Properties 5,6,7,8 are liveness properties. Properties 5,6 specify that Udeposit and Ufetch input messages must be eventually processed. Property 7 asserts that if Ufetch is requested infinitely often with ad-D then eventually an ou~ put message will be returned with uncorrupted data read from the address A. Property 8 sta.-
=!)
SPONTANEOUS INPUTS section which defines the input Lose. Lose g enerates messages spontaneously. It can force losing of elements each lime the queue is nonempty (-< in property 3 means "is a proper subsequence of"). Property 4 asserts that the processing of the Transmit request messages is fair, in the sense that if queue is infinitely often nonful then the request is eventually served and the messag e is put at the end of the queue. Similarly, property 5 states that the Receive request messages will be processed if the queue is infinitely often nonempty. Property 6 states that if a given element E is transmitted infinitely often and there are still attempts to receive elements then E is eventually received.
Specification and Design of Reliable Systems
l.)ESIGNING A
STABLE STORE
.!.\formal design oC a system is given by its stT'ucture specification. The constructs that describe the design are the system specification, the subsysterps specifications, the subsystems interconnection specification and the interlace specification. The system and subsystems specifications are given as module specifications, in the Corm introduced in the previous sections. The subsystem interconnection specification connects outputs to inputs among sUbsystems. The construct Sl.0LiT-.52.INP speciCies that the output OUT of Sl is connected to the input INP of S2. Then, if enabled01.JT( m; S2) holds Cor a g iven state s then aUNP (m) also holds for s. The interlace specification, given in the Corm SYS.INPi -
S1.JB.INF-j
139
6. Uread: POST IF IS_PendingW( serve) /\ OK THEN IF serve.dal-dt THEN IS _NIL('serve ) J\ enabledWrite (; server. who) ELSE enabledUwrite( ad-server.to,dt-server.dat) IF
rvOK THEN IF IS_Pending'V'l ( serve) THEN enabledUwrite ( ad~server. td,dt-server.dat) ELSE enabledUread( ad-server.from)
IF IS_PendingR(serve) J\ OK THEN IS_NIL ( serve) /\ enabledRead ( d-dt; server. who)
7. atUwrite: POST
IS_PendingW (serve)
<.l. Uwrite: POST enabledUread( ad-serve. to)
9. inUwrite -afterUwrite 10. inUread_sfterUread 11. inWrite" Write.d-D A Vv rite.at-A /\ SOURCE-S A C()IS_NIL( serve )rv...afterWrite J\ serve=(A,D,S)
or SYS.OLiTi -
SUB.OUTj
specifies that the input INPj of the subsystem SUB is used as the input INl'-'i oC th e system SYS , or that the output 01.JTj oC SUB is used as th e output OUTi of SYS. In this section we speciCy the n:odule Server and then d e fine 0. s tructur e which is the Corrllal desi g n (in terms oC subsystems Server and C store) of the stable store system specified by the module Store. The specification of the Server ['1o dule is c iven in Fig. 7. l'v:ODC;L E Server DOl'..;AINS ,) o.to.= Addr ess t ' endin g'vV =STHUC T( to:Address,dat:Data, who:I\ ': odnam e ) j ' endingR =ST 1<1.JCT (from:Address,who: l\,)odname)
12. inxead/\ React.at-A/\ S OUR CE.SA O()IS_NIL( serve)~afterReadA serve=(A,S) Fig. 7. Specification oC the Server module.
The meanin g oC the speciCication is as follows. Processing of a vVrite request sets the serve state component according to the parameters oC the request message and then repeat U write followed by U read until the Urcad response confirms that the data were stored correcUy (OKaTRUE ). Processing oC a Read re q uest sets the serve state component according to the requestin g message and then repeats Uread requests generated at the Uread output until receivin g an uncorrupted data (OK= TRUE ). The liveness properties 9,10,11,12 speciCy conditions under which the input message s oC Server ar e eventually proc e ssed. Formal desig n oC the stable storage system is shown in Fig. El.
IN'l'ERF/\C~
IN!·'I;TS V/ rite( at:Address,d:Dato.) r<. eact ( at:Address) 1.Jv:rite ( ) 1.J read( OK :DOOLE,c,,'\l,dt:Do.ta) OUTP UT S Write( ) I
SYSTEM
Storage
SUBSYSTEJ\-~ S
S erver, U store
CONNECTIONS Server.t:write-,. t.'store.Udeposit Server.Uread-_ Ustore.Ufetch Ustore.Udeposit~_ Server.Uwrite U store.UCetch-. Server.Uread
ST ATE serve:ONEOF ( ! 1 en ding'.V , Pe ndingx,N IL ) I:-:ITLll.L IS_NIL( serve ) BEHAVI 01.Jr< 1. atWrite: F OST ' " EXISTS m, n: ;i6 CUR r~ENTJ\ inServer(m) /\ SOURCE(m)SOCRCS 2. Wri t e : lORE IS_NIL( serve) ! j OST 's erve ~( at,d,SOURCE ) " enabledUwrite( ad-at, dt-d) 3.atRead: POST ' " EXISTS m, m;16 C1.JR RENT/\ inServer(m)" SOURCE(m)SOt.;l'<.CE 4. i
INTERFACE INPUTS Store.Deposit - Server. Write Store.Fetch = Server.Read OUTPUTS Store.geposit - Server. W rite Store.Fetch - Server.Read
J. G6rski
140
- Y§.Tf..H ___ ,
DEPOS IT r - - --I
STORE
I
I
I I
READ
WRITE SE RVER
UREAD
UWRITE UDEPOS IT
UFETC H
,........IikU-----z..L....;
I
USTORE
I L ___ _
F i g. o . Formal desi g n
of th e stable storag e.
CON C L t.: S I ONS
We hav e pres e ntl! d a me thod of m odule sp e cifica tion which allows for -
sp e cification of bo th, s afe ty and liven e ss prop e rties of the m odule , s p e cification of modules that are u se d concurrently, sp e cification of tol e rable failures, s truc tural sp e cification.
l'v: odul e sp e cification d es cribe s its possibl e behav iours by g ivinr, a s e t of properties which have to be satisfi e d by e ach individual b e h~ v iour (a hi s tory of states ). The properties impos e r e s t ricti o ns e ith e r o n the possible state tran s itions r e sultin c fro m th e m odul e 's inte ract.ion w ith th e e nvironment, or o n t h e w hole histori e s of s tates. Th e safe ty proper ti<~ s can includ e as s u m ptions about th e e nvironment of th e mo dul e , e. g. prop erti es 1,3 in th e specification of S tore . In particular, thes e assum ptions can restrict the amount of concurre ncy exercis e d w ith respect to th e module . S pontaneous inputs and nondete rministic post.c onditions allow for sp e cification of faulty b e haviours which can d l? p e nd on or be indep e nd e n t of thl? specific input stimulation. The corr e spondin g live n e ss pro pe rti e s restrict the occurr e nc e of faults in s tate histori e s and thi s way provide a g uarantee that th e c orr e ct behaviours ar e achiev abl l? , at l e ast to the e xtend which allow to tol e rate failur e s at th e hig her (system ) l evel. S tructural s p e cification s co m bine modul e sp e cifications into a form al d e si g n and link the d e si g n to th e hi g her l evel (syste m) specification. This is this system l e vel whe r e the lower level failures are tolerate d. This has been illustrated by a formal desi g n of the stable storage system. Evide ntly, a verification step is necessary to demonstrate that the desig n satisfies the specification of th e Store module. Such a verification would re q uire a d e finition of the state functions of Store in terms of the state functions o f U store and S erve r and then we would have to show that th e properties of the subsystems do not invalidate the properties speCified for the whole system. S uch a verification techni q ue is currently unde r deve lopment.
REFERENCES
Lamport L. (1983). Specifying Concurrent Program Modules. ACM Trans. P rogram. Lang. Systems, vol. 5, No. 2, 190-222. Lampson B. (1981). Atomic Transactions. In Distributed Systems: Architecture and Implementation, Lect. Not. Comp.· Sci., No. 105, 246-265. P nueH A. (1977). The Temporal Logic ~ Prog~. Proc. 1 8 th Symp. Foundations of Computer SCience, IEE E, Providence, 46-57. Schwartz L.R. and p. 1\·1 eHar-Smith. (1982). £.!:2!!!.. ~ Machines E Temporal Logic: Specification M e thods !2!' P rotocol Stan~. IEE E Trans. Comm., vol. CO M-30, N o. 12, 24 8 6-2496.