Pergamon

Comput. Lang. Vol. 22, No. I. pp. I-I 3, 1996 Copyright (0 1996 Elsewer Science Ltd

Printed in Great Britain. All rights reserved 0096-0551 96 $15 00 -c 0.00

AN EXECUTABLE SPECIFICATION LANGUAGE FOR FAST PROTOTYPING PARALLEL RESPONSIVE SYSTEMS

H. HEPING’ and H. ZEDANZP

‘Domino, 43 Green End Rd, St Neots, Cambridge PE19 lSE, U.K.

‘Computer Science Department, De Montfort University. Leicester LEI 9BH, U.K

(Received 21 June 1995; revision received 11 March 1996)

Abstract-An executable specification language, known as PSP, for fast prototyping parallel responsive systems is introduced. The language is equipped with directly executable mathematical data objects. first order predicates, temporal operators, parallel assignment, state and state history, sets, maps and sequences, etc. An abstract system model of a parallel responsive system may be constructed using PSP. Using this model, various dynamic behaviors of the system can be studied and analysed at an early design stage. These include detailed temporal relations between every component in the system. Temporal and functional properties of the system can also be expressed within PSP as (temporal) predicates. Global cause-effect relations and other temporal properties of the system can be tested by executing both the abstract system model and its associated functional/temporal assertions. Inconsistency and incompleteness in the abstract design can then be discovered against user’s intention before real implementation. thus reducing design cost. PSP is illustrated using a lift system. Copyright (I’m 1996 Elsevier Science Ltd

formal specification prototype reactive parallel system

1. INTRODUCTION

Parallel responsive systems consist of two or more reactive sub-processes that continuously cooperate to achieve a pre-defined goal [l]. A typical parallel reactive system contains at least one controller which controls many physical devices. Examples of such systems may be found in avionic, multi-level industrial processing and medical applications.

Parallel responsive systems are complex computer systems, and may not be modeled by transformational techniques. A transformational technique is input driven in which a set of input values are read, processed, a set of output values are produced and the system then terminates. Such systems are well described by a relation between sets of input and output values. Parallel responsive systems on the other hand are multi-input-output driven systems. In principle, the behavior of the entire system depends on the reaction between controllers and the controlled devices. The difference between the input driven and the input-output driven is the notion of feedback and multi-feedback. Time and order of the system values play important roles in the computation: the same set of output values of system components at a different time or in a different order makes a totally different effect to the system level behavior.

There have been many formalisms and tools dealing with the specification and design of parallel responsive systems. In [l] four types of formal specification methods are introduced and compared, namely the state based systems (e.g. statecharts and SDL; Petri nets); logic-based systems (e.g. PARLOG); and programming-oriented approaches such as CCS, CSP, ESTEREL and LOTOS. None of these approaches are sufficiently able to specify the time or the order of feedback (reactive) relations between all the system components against the system’s physical configuration and user’s intention.

Validation of an abstract specification of a parallel responsive system is an important aspect of system design. One approach of validation is the ability to specify and design the system within

tAuthor to whom correspondence should be addressed.

H. Heping and H. Zedan

Physical device System feedback

Fig. 1. A PSP device model for a responsive system.

a unified formal framework that is supported by a powerful, expressive and executable specification formalism.

In the quest of a prototyping tool for the formal development of a parallel responsive system, we have designed a specification formalism that allows the expressibility of both functional and timing requirements of the system within the same framework. The associated programming environment, known as PSP, is an executable subset of such formalism. Within PSP, an abstract model of a parallel responsive system or a distributed system can be specified, tested and validated.

In this paper we describe the PSP language and show how it models the cause-effect (reactive) orders between the concurrently running system’s components. Section 2 overviews the system model. Section 3 introduces some basic mechanisms to handle system states, state history, simultaneous component state transitions, temporal assertions in parallel processing and cause-effect relations between the concurrently running components. A computer controlled lift system in an n-floor-building is prototyped to illustrate the language and the program is listed in the Appendix. The syntax of the language is also listed there.

2. THE SYSTEM MODEL

In PSP, a parallel responsive system is modeled by a set of abstract devices which act and react with each other concurrently within certain cause-effect constraints. Each abstract device can be considered as an independent processor with its own program to simulate the behavior of the device.

The abstract device model of a parallel reactive system consists of six basic types of component. The physical device, sensor device, actuator device, communication device, controller and clock device. Various equipment or processing configurations may also be included (see Figs 2 and 3).

A physical device can be modeled by a function implementing its physical law and effected directly by related actuator devices. An actuator device can be prototyped as a boolean

Actuator Actuator

Fig. 2. A PSP device model for a parallel processing system.

Fast prototyping parallel responsive systems

Fig. 3. A PSP device model for a parallel computing system.

Processor Comm Processor

function or boolean statement in a physical function to switch on/off certain actions of the physical device. A sensor device can be prototyped to sense a physical device function and report its behavior concurrently to a controller. A controller is an abstract device denoting embedded computer software. It is modeled as a set of PSP programs expressing requested reactive relations between sensors and actuators. It collects assertions from sensor devices or values from the controlled physical devices or communication channels, computes, then outputs certain values

to actuator devices to constrain the controlled devices. Environment events can also be modeled by a sequence of inputs from outside the system and indexed by the user defined global clock. Clocks are also abstract devices and modeled by functions within the parallel assignment that increment state variables. Running the parallel assignment sequentially, all the above devices may act and react with each other concurrently according to the specified requirements.

User’s temporal requirements over the system are programmed by state predicates in PSP over the system history.

Time in PSP is modeled by a set of discrete time points, we call them timing ricks. These ticks are isolated and counted by a tick counter which should be specified explicitly in the specification as an independent device. One or more clocks can be specified to allow various timing granularities

to be modeled. Time is only allowed to advance within the parallel assignment (see Section 4). The value of a tick counter represents the step at which the system transition has been performed. The system may start at tick 0 and may have a finite number of ticks (0 . Nj. Lengths between two ticks might be variable or constant. For convenience, a constant length is normally assumed.

An example of a computer controlled lift system is given to illustrate the language. The system is to carry persons to travel between different floors in the building. When an outsider pushes an up/down button at a floor, the lift is called and will be at that floor and stop after a certain time with its door open. When an insider pushes a numbered-button at the panel inside the lift, the lift will go to that floor, stop and open the door. When more than one button has been pushed down at the same time, the computer will schedule the lift to keep its direction as far as possible while giving the insiders the highest priority. The prototype is simplified to show the controller is working

correctly and whether the scheduler is sound. PSP will model the motor, door, position of the lift, a set of up buttons and a set of down

buttons, a set of panel buttons and the controller as independent devices that act and react with each other in parallel. Human activities are modeled by timed events which are sequences of time stamped sets representing up buttons, down buttons and panel buttons that have been pushed

down at that time. They are the system input to the prototype.

3. STATE VARIABLES AND PREDICATES OVER STATES

State variables in PSP are global variables recording the values of system devices over a global clock. Values of state variables are called state values. They represent the observable behavior of a system. The set of state variables is called the system state space. PSP provides temporal operators to refer to a state value over its history. System state space should be declared at the beginning

4 H. Heping and H. Zedan

of a prototype and followed by all of the system variables shown in the following skeleton.

prototype (id) DATATYPE:(type) TME:int

STATE: : vah:(type),

w-2 : (type > , . . .

var, : (type >, T: TIME

(function definitions) end

where varj is a state variable with a certain data type. T is the tick counter (clock) and also a state variable. The value of var, at the Ch previous tick may be obtained using the P operator of P(i)var. If P(i) is omitted, the value of uarj at the current tick is given. The P operator can only apply to state variables.

We define the state space of the lift system as below.

prototype A-Lift FLOOR PANEL POSITION STEP

FLOORS UP-BUTTONS DOWN-BUTTONS LIFT- PANEL

SYS-IN :

STATE : : up-buttons down-buttons panel-buttons position direction motor door step

(function definitions) end

: int : int : int : int

: set of FLOOR : FLOORS : FLOORS : set of PANEL

seq of (STEP,UP_BUTTONS,DO WN_BUTTONS,LIFT_PANEL)

: UP-BUTTONS, . DOWN-BUTTONS, ; LIFT-PANEL : POSITION : bool, : bool, : bool, : STEP

where the state variable up-buttons has a type of a set of int and records which up-buttons at different floors have been pushed down at a time point. position has an integer type, denotes which floor the lift is at during that time. direction is a boolean device which denotes at the time whether the direction of the lift is up. motor denotes a “motor is on” state. door denotes the “door is open”. step is the time tick counter and defined by the user as an abstract clock to index time steps of the model. Values of these state variables at different steps are recorded automatically as a system state history.

To express temporal properties PSP uses state predicates which refer to the current or any previous values of state variables. In PSP, state predicates are first order predicates over the state history. Unlike other temporal logics, state predicate in PSP handles only the current, the past and the historic facts. Thus no next operator is built into PSP but only the previous (P) operator. For instance, a PSP program:

Vi E (0. . . k).pred(P(i)var)

Fast prototyping parallel responsive systems 5

asserts that pred(P(0)var) r\pred(P( 1)var) A . . r\pred(P(k)var), where pred is a first order predicate. Other logical connectors e.g. A, v, 1, +, tt may be used. The above fragment states that pred(var) holds for the recent k steps or k time ticks. The following state predicate in

PSP specifies a safety property of the lift system:

s.1 ViE{O... step}. 1 (P(i)motor A P(i)door),

where step is the abstract clock and its value denotes the longest step. The property states that for all steps in the past, the motor on and the door open will never appear at the same time. Vi c 10. . k).pred(P(i)var) and 3 E (0. . k 1 .pred( P( i) var) provide the general facilities for temporal assertions over the whole system history. For convenience, the following two temporal

operators are implemented in PSP. They are always and sometimest:

always(pred(var)) z Vi E (0. step).pred(P(i)var), (1)

sometimes(pred(car)) r 3 E (0. . step}.pred(P(i)var). (2)

The first says that pred is true for all ticks in the past and the second says that prcd is true for

some ticks in the past. s.1 above can be expressed in PSP as:

s.1 always( 1 (motor ~door)).

These temporal operators obey the following inference laws:

always(always(pred)) t) always(pred) sometime(sometime(pred)) t--f sometime(pred) always(sometime(pred)) ++ sometime(pred) sometime(always(pred)) t+ always(pred) always(pred) --f sometime(pred) pred -+ sometime(pred) -~always(pred) tf .sometime( Tpred). (.3)

For a complete list of laws see [2]. Since first order predicates are implemented in PSP, other temporal operators can also be defined by the user in a similar way. For instance, the strong until operator can be defined as below

until(,f: g) Z 3i E {0 . . . step}, Vj E (0 . i}. (i P(j)f A P(i)g), (4)

whereJ’and g are state predicates. Thus various user requested temporal properties can be presented as state predicates over the system history.

4. PARALLEL ASSIGNMENT AND SIMULTANEOUSLY REACTION

Parallel assignment, or defta assignment in PSP, has the following form:

delta(

varl = expression, car: = expression, . var, = expression, T= T+j

L

where var, is a state variable which has been declared in the state space; expression is any expression including function calls. var, = expression is called a sub-assignment in a delta statement, which determines the new external value of the corresponding state variable at the next time tick. Computation of these sub-assignments are modeled within the same time tick. All the sub-assignments inside one delta statement commence and terminate in parallel over the same time

tNote that these are different from the temporal logic operators 0 and 0. up asserts that p is always true rather than always(p) which asserts that p has always been true.

6 H. Heping and H. Zedan

ticks of (T + j). There is no syntactical sequential order among these sub-assignments and they can be written in any order within the delta statement. The main difference between the delta assignment and the conventional assignment list is that in delta statement, the value of the LHS of a sub-assignment becomes available only after the termination of that delta statement, not after each sub-assignment.

Sequential execution of delta assignments produces a sequence of system state transitions, in which all of the state variables change their values simultaneously. A sequence of executions of the delta assignment is programmed as in a normal programming language with sequential compositions (;), conditional statements, (if then else) and function definitions and function calls. The following functions of Some-step and Simulation are such programs for the lift system.

fun Some-step (time’:STEP,new_up: UP_BUTTONS,new_down:DO WN-BUTTONS, new_panel:LIFT_PANEL)r: boo1

n = if (step + 1 > time’) then true else if (step + 1 = time’) then(

delta ( up-buttons =

new-up sor Clear_up_button(up_buttons), down-buttons =

new-down sor Clear_down_button(down_buttons), panel-buttons =

new-panel sor Clear_panel(panel_buttons), position = Change-position0 , direction = Change_direction(), motor = Change-motor{), door = Change-door 0, step = step + 1

); ) else (

delta ( up-buttons = Clear_up_button(up_buttons), down-buttons = Clear_down_button(down_buttons), panel-buttons = Clear_panel(panel_buttons), position = Change-position () , direction = Change-direction 0, motor = Change-motor (), door = Change_door(), step = step + 1

); Some_step(time’,new_up,new_down,new_panel)

fun kmulation(sys_in : S YS_ZN) = ^ if (sys-in ! = emptyseq) then(

let val new-em = hd sys-in val (time’,new_up,new_dwn,new_panel) = new_env

in{ Some_step(time’,new_up,new_dwn,new_panel); Simulation(tl sys-in) ) end

)else( Some_step(step + 1 ,emptyset,emptyset,emptyset);

In the delta statement at the lower branch in the function of Some-step, all of its sub- assignments do not input the new values from the system input. The system depends only on its

Fast prototyping parallel responsive systems

previous the higher branch, the take values from Some-step, because the clock (step + 1) equals to the current event stamp (time’). The function of Simulation inputs a sequence of events denoting the human operations and organises a sequential

progress of Some._.step.

5. THE CAUSE-EFFECT RELATIONS AND THE PARADOX BREAKING

PSP does not simulate the processing time or the process duration, instead, it models the orders

of value changes over transition steps or the cause-effect relations between all system components. In PSP a step has the zero duration and is marked by a global time tick. The length between two steps in PSP is left unspecified and can be modeled by the programmer. In this way, the fastest

reactions can be modeled with zero durations comparing with the slower reactions. The slower

reactions can then be modeled by certain delay modes. In 131, the zero time transition has been fully discussed, and we emphasize that firstly, at the

abstract specification stage, the most important property of a complex parallel reactive system is the ordering in which the system components react with each other. Without understanding the order or the cause-effect relation between the actions of the components, the requirements about timeliness or durations are meaningless. Secondly, constant action durations are hardly found in

reality. Thirdly, a variable duration for a real process is very difficult to specify and to simulate. In general, it is almost impossible to know the detailed temporal durations for every process at the early design stage. Thus modeling the accumulated processing time in an abstract specihcation

is not a wise choice and might overspecify the problem. Consider the simulation of a lift system in PSP. If we would like to specify durations for every

real process in the PSP program, e.g. the motor, door, lift position, etc. we will soon face a difficult task to calculate all of the possible timing parameters for each device even before we select the exact equipment. It obviously overspecifies the problem.

However, using the zero duration in PSP. the fastest reactions can be modeled within the same tick and the slower reactions can be programmed in different steps. In this way, a PSP prototype models sufficiently the orders in which the system components react with each other without actually knowing the duration of every process.

In reality, systemPvalue-changes are neither totally sequential nor totally independent. One state value change might depend on many other state values. Most state variables possess some kinds of cause-efltict relations and such relations can be quite complicated. For instance, the motor on

will cause the position of the lift to change and the door close and some lift calling may cause the motor on. There are certain sequential orders or time delays between cause-effect pairs. In PSP

both the cause and the e&f&t can be modeled to happen at the same time (i.e. zero time delay). This produces a traditional conflict of “how to preserve a sequential ordering within the zero time”.

In PSP, this problem is solved by sequential processing inside a delta assignment. A list of local assignments inside a delta statement provides a mechanism for sequential

composition within a parallel assignment. These local assignments are sequentially ordered and performed within the same step as its delta assignment, and modeled to take no computation time.

For instance, if u causes h and they occur at the same tick, we can program this in PSP as,

let val A = process(s)

val B = process( A,y)

in delta(a= A,h= B, T= T+ 1)

end

The state variable b does not depend on the previous value of the state variable a and vice versa. However processing of b does depend on the current value of processing of a, (i.e. B = process(A, y)), and all of these complete at the same step.

The causeeffect loops in reactive systems are common phenomena, and they are one of the main characteristics that differentiate parallel reactive systems from transformational systems. For instance, switching on the motor causes the position of the lift to change and changing the position of the lift can also cause the motor to switch of. So a simple causeeffect relationship of

8 H. Heping and H. Zedan

“motor state change will cause lift position change” cannot describe the above phenomena. They are a kind of cause-effect loop.

A cause-effect loop has to be broken in time by comparing the timing granularities and active modes of the processes in the loop. For cause-effect pairs with the different timing granularities, the slower process has to be delayed by one or more steps. Thus, the slower process can be processed firstly and its data reference depends on the previous values of the faster processes. For cause-effect pairs with the same timing granularity, the process representing the controlled (reactive) device can be delayed by one or more steps, while the active process representing the controller can stay as the faster process.

For the lift example, compare the motor and position. Position changing is slower than changing of motor, so that position can be simulated as depending on the previous value of motor, The relevant PSP program is as below,

let val Position = Change_position(motor) val Motor = Change_motor(Position)

Fast prototyping parallel responsive systems 9

Executing a prototype, some incompleteness and inconsistence about the modeled system can

be disclosed to motivate further modifications of the abstract design. Keeping an abstract prototype in hand will also help the future maintenance. So, specification and prototyping a parallel reactive

system in PSP will reduce the cost, both at the abstract design stage and at the maintenance stage in the life cycle of the development of a parallel responsive system. Various case studies have been done which include a safe pump system, a railway crossing, a traffic junction control, an automatic

door. etc. [4-71. The PSP is not suitable to prototype a very large parallel responsive system now. Its fixed system

state space declaration makes it difficult to be programmed in an object-oriented manner. The fixed

state space also limits concurrency of the processing and makes modeling of dynamically generated and destroyed program processes difficult.

I 2

3

4

5

6

7

8 9

IO

II

12 13

14

IS

REFERENCES

Furbach, U., Formal specification methods for reactive systems. J. Q.rtems Sqfrware 21: 129.-139; 1993. Pnueli. A.. The Temporal Logic of Programs, Proc. 18th Ann. Symp. Foundations of Computer Science. Providence. RI. New York. IEEE. pp. 4657; 1977. Huizing, C. and de Roever, W. P., Introduction to design choices in the semantics of Statecharts. I~formarion Procrssinq L2lter.c 37: 205-2 13; 199 1. Heping, H., C!,cle Calculus for Requirements Specification of Real-time and Hybrid Systems. FSRG reports, FSRG-93-18. Department of Computer Science, University of York; 1993. Heping, H., PSP, a Programming Language for Prototype State Predicates. FSRG report. FSRG-93-19. Department of Computer Science, University of York; 1993. Heping, H. and Zedan, H., Requirement specification for real-time and hybrid systems, Proc. 6th Conference on Formal Description Techniques. Boston, U.S.A.; 1993. Heping. H., The cycle calculus and method for the formal development of real-time and hybrid systems. Ph.D. Thesis, Department of Computer Science, University of York, YCST9407, July 1994. Allen. J. F.. Towards a general theory of action and time. Artificial Intelligencr 23: 123-154; 1983. Rescher. N. and Ilrguhart. A., Temporal Logic. Vienna: Springer; 1971. Jahanian. F. and Mok. A.. Safety analysis of timing properties in real-time systems. IEEE Tram S.E. 12(9): 89@-940; 1986. Chaochen. Z.. Hoare, C. A. R. and Ravn, P. A., A Culculus @Durations, ProCos Working Paper. Oxford University Computing Laboratory; 1991. Moszkowski. B.. Ewcuting Temporal Logic Programs. Cambridge Tech Report Nil; 1985. Kroger, F., Temporal Logic of Programs, EATCS, Monographs on Theoretical Computer Science (Edited by Brauer, W., Rozenberg. G. and Salomaa, A.) New York: Springer. Kesten, Y. and Pnueli, P.. Timed and hybrid statecharts and their textual representation. In Formal Techniques m Real-Time arIdFault-T~~k~,rant Systems, Vol. 571 of Lect. Notes in Comp. Sci. (Edited by Vytopil. J.), pp. 591 619. New York: Springer; 1992. Maler, 0.. Manna. Z. and Pnueli. A.. From timed to hybrid systems. In Proceedings of the REX Workshop ReaI-Time: Theor\. itI Prac~trce. Vol. 600 of Lect. Notes in Comp. Sci. (Edited by de Bakker. J. W.). New York: Springer: 1992.

APPENDIX

Appendix A. Syntax of PSP

Terms in this appendix is similar to BNF such that “::=” denotes “is defined as”, ,‘I” denotes “syntactic or”, “...” and I’. ,..,” denote “obviously repeats” and block bold denotes “is an atomic token”.

1. Prototype and a Run

PSP ::= prototype_dejinition 1 prototype_runntng

prototype_de~Fnition:r=prototype nomc type_dcc/orotion stotement_list function_defs end

prolotype_runnu2g ::= stafemcnl_liat

2. Type System

typr_declaralion ::= Lype_list ( state_variobles

type-M ::= type_name : type 1 type_name : type type_/irl

stntc_uorioblcs ::= STATE :: siote_vor : type , state_var : type ( . . . . . . stnlc_var : type

type ::= basic-type 1 composite_type

ba.&_typc ::= int 1 real 1 boo1 1 string 1 unit

composile_type ::= set of fype 1 map type to type I SW of type I bag of type I ( type , . . . . . . ) I name :: label: type , . . . , lobe/: type

IO H. Heping and H. Ze.dan

3. Functions

function_hejS ::= /unction_dejinition function_de/s

Junction_definition ::= function_head =- function_body

funcfion_hcad ::= fun name ( org_“ame : type, . . . ) out-name : type

function_body ::= statement

4. Statements And Assignments

s2otement ::= simulfaneously_ossignment 1 assignment 1 conditional 1 czpression 1 ( stalement_lirt

/oca/_assignment 1 ) 1 routines

simul~aneour/y_assignmen~::=delta(~tate_vo~elpresrion,...,stafc vor=ezprerrion)

assignment ::= val ni1m.5 = erprersion 1 val ( name , . . . . . . , nmnc ) = luplc_ezpr

1 val name mern set_ezpr

locol_ossig”ment ::= IeL oraingme”t_list in czpresrio” end

ossignmcnt_list ::= arrignment 1 wnignmcnt ; orsignment liat

conditional ::= if logic_erpr then rtalement else rlotcment

routines ::= open proto_name I include ” file_nome ” I Wit erpr 1 quit

5. Expression

ezpression ::= nrithmctic_czpr I logic_tzpr I string_erpr I sct_ezpr 1 mop_ezpr I req_ezpr

I bag_ezpr I tuple_czpr I record_ezpr 1 Lemporal_ezpr I opcrated_ezpr I vw_“ome

I jun_cal/ I graphic_ezpr

5.1. Logic Expression

logic_ezpr ::= normal I first_ordergredicatcs 1 tcmporal_operationr I ob~troct_lype_re/otions

jirst_ordcrgredicofea ::= (ford nomc mam sef_ezpr suchthat /ogic ezpr ) 1 (exists name mem sef_erpr suchthat k+c erpr ) ( (unique nome mem set_ezpr suchthat logt?_ezpr )

I (forall nsmc , name mem rct_erpr suchthat logic erpr ) I (forall n_tuple_“ome rnem re?_crpr suchthat logiclezpr ) I (exists “_tuple_nome mem set_ezpr suchthat logic ezpr )

I (unique n_luplc_“ome mem art_erpr suchthat /ogt<_ezpr )

“_tuple_“ome ::= ( name , . . . . . . , nOme ) temporal_operotions ::= always( /ogic_ezpr ) 1 sometime( /ogic_erpr )

obstract_type_relotions::=set_ezpr sel_relalion srt_erp~ezpreaaion cquol_relafion erpresrion

I ezppr mem set_ezppr I ezpr runem set_ezpr I seq_ezpr subseq scq_erpr

I is_disj seq_ezpr I isgartition( req_ezpr , set_erpr )

set_relation ::= sine I ssinc

equal relation ::= = I !=

Note, unique denotes ezists only one; always denotes all previour; rometime denotes a1 /earl once in previous, sine, knc denote sub-&, proper sub-set.

5.2. Set Expression

set_ezpr ::= sel_ge”eralion I sct_opcration

set_gcneralion ::= emptyset I { ezppr , . . . . . . , e*ppr } I { forall nsmc mem set_ezpr suchthat logic_czpr with ezpresrion } I { forall nome mem set_ezppr ,

name mem ret_erpr ,

name mem set_ezpr

suchthat logic_ezpr with expression }

I dom map_ezpr I ran map_czpr I opimg mop_erpr climg I maptoset( mop_czpr ) I seqtoaet( req_czpr ) I bagtoset( boq_ezpr )

set_operalio” ::= set_opZ bct_ezpr I ret_ezpr bet_opl sel_erpr

set_opl ::= ps ) dand I dor

set_op2 ::= SOP I sand I ssub I sdif

Note: ps denotes the power set; dand, dor denotes dirtribuled intersection and dirtributed union; SOI; sand, asub, sdif denote set union, set intersection, ret rubtract, ret differenti when rl rdij a2 = rl - a2 u a2 - al. dam, ran

denote domain, range of a map; opimp, climg denote the image of a map.

Fast prototyping parallel responsive systems

5.3. Map Expression

map ezpr :I= mopgeneration 1 map operation

mop generation I:= emptymap ( ( erprf mlet ezpr2, . . . . . . , czpri mlet ezpr2 ) ( id set_crpr 1 settomap( ret_erpr ) 1 seqtomap( seq_czpr ) 1 bagtomap( bag_ezpr )

map_opcralion ::= ( sct_ezpr domain_ops mop_czpr ) 1 map_czpr range_ops ret_crpr

1 mop_ezpr mop_opt map_ezppr I map eqr rtc integer_ezpr 1 mop_erpr inv

d omain ops ::= dres I dsub

rangc_ops ::= rres ) rsub

mnp_opz .:= fxov 1 rc I frc

Note, drea, VW, daub, raub denote domain rerkic&n, range restriction, domain subtraction, range rublraction; fzov

denotes June&n overrides; w, frc denote relation composition, forward comporifion: inv denotes mop inversion; rtc denotes self-composition n times; id denotes aa identity map over a set.

5.4. Sequence Expression

teq wpr ::= seq_generntion ) scq_opcra:ion

scq_generaalion ::= emptyseq I [ rrpr , . . . . . . , czpr ] I settoseq( rcl_ezpr ) I maptoseq( mop_ezpr ) I bagtoseq( bag_ezpr )

seq operalron I:= seq_opl seq_ezpr ( scq_e*pr seqcat rep czpr 1 seq_ezpr SeqOv map_czpr

seq_opt :I= tl 1 front 1 rev 1 dseqcat 1 dseqmap

Note. scpco( denotes the sepucncc concawut~u,,,; scqou denotes the xcpu~ncc oucrruimg; 11. front denore w&out firsi. without lasi; rev denotes reucr~c J~~UC~CL; dscqcat, dsrqmap denote dislrrbutrd sequence concolcnatwn, distrsbutcd

sequcncc Inupping.

5.5. Bag Expression

b ng c~pr ::= bag_gcncrallon I bag_czpr bagor bag_ezpr

bag_generation :I= emptybag ( ( crpr frqt integcr_ezpr , . . . . . . , ezpr frqt ~ntcgtr_crpr ) \ settobag( rct_rrpr ) 1 maptobag( mtrp_erpr ) ( se@obag( *ct_cr~r )

Note, bngor denotes bag union; count denotes counting jrcqucncy

5.6. N_Tuple, Record. Temporal and Other Expressions

tup1c_ezpr ::= ( czpr ( . . . . . . , ezpr )

record ezpr ::= mk : record type ( czprtsrion , , crprcrrion ) I u: record Type (rccord_erpr , label = rrpr , label . .,. , lab.4 = ctpr )

tcmporni_ezpr :I= stotc_vor I P stdr_vnr 1 P( integer_e+pr ) stotc_vor

opcratrd_erpr I:= hd *y_ezpr 1 last ~cq_czpr / ( intcger_czpr th scq_ezpr )

I ( mclp_ezpr from ezprersion ) I get lobtl record_crpr

/un_call ::= “OrnL ( c*pr , . . . . . . )

Note. P state uar denotes previous unlue of jtatc VOT: P(i)stntc_var denotes fhe ,I* prewous uaiuc 0,‘ state_uar: hd.

last denote th; first, the last element in a sequence: /ram denotes a mop apply.

prototype An N Floor-Lilt - -

FLOOR:int PANEL&t POSITION:int STEP:int

: LIFT PANEL. panel_buttons position POSITION, direction : bool. motor : bool, door : bool. step : STEP

FLOORS: set of FLOOR val UP BUTTONS: FLOORS VZ31 DO-WN_BUTTONS: FLOORS val LIFT-PANEL: set oI PANEL

fun SYS_IN: seq of =

(STEP,UP_BLJTTONS,DOWN_BUTTONS.LIFT_PANEL~

STATE:: up-buttons: UP-BUTTONS,

down buttons : DOWN_BUTTONS. fun

N = 12; (’ 12+1=13 Boors ‘) HOLD-DOOR = l:(* on panel *) CLOSE DOOR = - ‘;(’ on panel l )

Been_served(r:int)r:bool iI (P(t)step > 0 and not (P(t)door or P(t)motor)) then if (P(t + 1)door)

then true else Bccn_served(t + 1)

else k&e Highest_req()r:bool

12 H. Heping and H. Zedan

Appendix B. A Lift Prototype

Fig. 4. Device model of a computer controlled lift system.

=-

fun =‘

fun =-

fun =

fun =

=-

if (down buttons sor up-buttons != emptyset) then p&ion =

max_min(down_burrons sor up-buttons, true) else f&e Lowesr_req()r:bool if (down buttons SOT up_burrons != emptyset) then p&ion =

max_min(down_burtons SOT up_buttons. L&e) else false

Changegosition()r:POSITION if (motor and position = P position) then

if (direction and posirion != .N) then position + 1 else if ((not direction) and p&lion != 0)

then posirion - 1 val req_when_motoroff =

((position mem panel_buttons) or (direction and (position mem up-buttons)) or (not direction and (position mem down-buttons))) and not motor and not door

val press cl but = door and-( CLOSE-DOOR mem panel_bnttons)

val door_opend_awhile =

in (( not motor) and P door and door)

if (motorjust_stop or req_when_motoroff) then true else if(press cl but or door_opend_awhile)

then f&e - else door

end Clearganel(p_b:LIFT_PANEL)r:LIFT_PANEL if (door) then if (CLOSE_DOOR mem p-b)

then (p-b ssub {position, CLOSE_DOOR}) else (p-b ssub {position})

else p-b Clear_up_button(up_b:UP_BUTTONS)r:UP_BUTTONS if (door and

(direction or (not direction and Lowest_req()))) then (up-b ssnb {position}) else up-b Clear_down_button (down_b:DOWN_BUTTONS)r:DOWN_BUTTONS if (door and ((not direction) or

direction and Highest req())) then (down-b ssub {p&ion)) else down-b Some step (time?STEP,new_up:UP_BUTTONS, new_down:DOWN_BUTTONS, newganel:LIFT_PANEL)r:bool

=-

fun =-

fun =^

Fig. 5. PSP report of the lift model.

if (step + 1 > time’) then true else if (step + 1 = time’) then(

delta( up_bnttons =

new_up sor Clear_np_button(up_buttons), down_buttons =

new-down sor Clear_down_button(down_buttons), panel_buttons =

newganel sor Clearganel(panel_bottons), position = Changegosition(), direction = Change_direction(), motor = Change_motor(),

door = Change_door(), step = step + 1

,a: ()

)e% delta(

up_buttons = Clear_up_button(up_buttons), down_bnttons = Clear_down_button(doWn_buttons), panel_buttons = Clearganel(panel_buttons), position = Changegosition(), direction = Change_direction(), motor = Change_motor(), door = Change_door(), step = step + 1

Some_step(time’,new_up,new_down,new_panel) j kmulation(sys_in:SYS_IN) if (sys_in != emptyseq) then(

let val new env = hd sys_in val (tim>, new_up,new_dwn.new_panel) = new_env

4 Some_step(time’,new_up,new_dwn.new_panel); Simulation(t1 sys_in)

)end

)el=( Some_step(step + l,emptyset,emptyset.emptyset);

) Init_state(maxdelay:int) if (maxdelay >= 0) then( delta(

up-buttons = {}, down_buttons = {}, panel_buttons = {}, position = 0, direction = true, motor = false, door = true, step = - maxdelay

); hit_stste(msxdelay - 1)

)eI= 0

Fast prototyping parallel responsive systems I3

end, =

open An N Floor-Lift; Init_stat’e(3j; d SYSO = [(L {1,3,5},{},{}),(10,{},{6,2},{}),

(20,{},(3},{0,4,8,7}),(3O,I),I),I))); Simulation(sys0);

else position else position

fun Change_direction()r:bool = let val up-request = (exists i mem

(up-buttons sor down-buttons sor panel-buttons) suchthat i > position)

val down request = (exists i mem (up-buttons sor down-buttons sor panel-buttons) suchthat i < position)

in if (Been-served(O) and (up-request or down-request)) then if (direction and up-request)

then true else if (not direction and down-request)

then false else not direction

else direction end

fun Change_motor()nbool

fun =

let val request-this-floor = (

(position mem panel-buttons) or ((not direction) and ((position mem down-buttons) or

Lo=t_reqO))

;lIir t’ ec Ion and ((position mem up-buttons) or Highest_req())))

val other-request = (exists f mem (up-buttons sor down-buttons sor panel-buttons) suchthat f != position)

in if (P motor = motor and not door) then if (motor and request_thi_tloor)

then false else if (Been_served( 0) and other-request)

then true else motor

else motor end Change door( )r: boo1 let val &otorjust_stop =

(P motor) and (not motor) and (not door)

About the Author-Prof. H. ZEDAN began his research career at Cairo University where he gained his M.Sc. in mathematical logic in 1977. He was awarded a Ph.D. in mathematics by the University of Bristol in 1982. He worked in various British academic universities and he is now a professor of Computer Science at De Montfort University. His research interests include formal specifications and verifications, the design of distributed/concurrent languages, concurrency theory and time critical distributed computing systems.

About the Author-Dr. H. HEPING obtained his Ph.D. from the University of York, U.K. in 1995. He is currently working as a software engineer in Domino Ltd, U.K. His main interests are formal specification and design of reactive systems.