- Email: [email protected]
The formal specification of concurrent systems: a small CCS case study
htformation and Software Technology 1994 36 (11) 667-673
The formal specification of concurrent systems: a small CCS case study I M Bradley Department of Computing, University of Northumbria at Newcastle, Newcastle upon Tyne NE1 8ST, UK
Building complex, concurrent systems requires a large amount of care. Such systems often have many interactions between components. Some of the more obscure timing patterns can lead eventually to system failure. It is essential that any problems be identified as soon as possible in the life of a project. This short paper is intended to demonstrate how the behaviour of a concurrent system can be specified using CCS. Various models of the system are presented and discussed. We show how having developed a 'black box' specification of a system it may be refined and that refinement verified against the original specification. Finally we show how modal and temporal logic may be used to express desirable properties of the system. Keywords: formal specification, CCS, process algebra, modal logic, concurrent systems, temporal logic
It is widely recognized that the requirements specification for a system can be vital for the successful development of that system. Concurrent systems provide a particularly difficult area for specification because of the potentially complex interactions that can exist between the system components. Yet because many concurrent systems also exhibit real-time requirements and may be safety critical their correct specification is of particular importance. For many years so-called structured methods, such as MASCOT ~, RTSA 2 and DARTS 3 have been used to build requirements models of concurrent real-time systems. Although these methods provide a vehicle for analysing concurrent systems they are deficient in several aspects. Firstly because they are not firmly based in mathematics there is no formal proof obligation between levels of refinement that are identified during the analysis stage. Further there is no method of proving that the structured specification captures the desired properties of the systems. In the case of real-time safety critical systems these may be absolutely essential safety requirements. If the absence of such properties is not detected at an early stage in the project, i.e. at the specification stage, expensive rework of the project can result. If the omission of such properties is not detected until after implementation then the results could be catastrophic. An example of such a development was the case of Therac-254. This system, designed to provide radiation therapy, failed as a result of software errors, with the result that several patients died and others received large unsafe doses of radiation.
0950-5849/94/011667--07 © 1994 Butterworth-Heinemann Ltd
In this paper we will present a short case study intended to demonstrate how we may use formal methods, and in particular CCS 5, to capture the requirements and model the behaviour of concurrent systems. We begin by presenting a short introduction to CCS: this is followed by the development of the specification for the example that is the subject of the case study; and some modelling issues will be discussed. Finally we will show how a modal and temporal logic can be used to represent the desired features of our system and explain how these representations can be used, with software support, to help validate the specification.
Overview of CCS The Calculus of Communicating Systems, CCS, belongs to the set of formal methods known as process algebras. It models concurrency in terms of communicating processes, discrete events, asynchronous execution, and handshake communication. A CCS model consists of a set of agents (processes), and events (actions). Events are regarded as atomic actions indivisible with time. In the following we will provide a short basic introduction to CCS. It is not the intention to present a full description of the semantics of the method but rather to enable the reader to follow the specification presented in the main part of the paper. A fuller description of CCS can be found in Milner 5. In CCS we could model a door which can open and close as:
667
A small CCS case study." 1 M Bradley
Door:: = open.close.Door This definition defines an agent D o o r that first performs the action open, then the action close and then behaves as a Door, i.e. it represents a door that can continually open and then close. This definition introduces several features o f CCS. First we note some simple syntactic conventions. The names of agents must start with a capital letter and the names of events must start with lower case letters. The definition introduces the sequential operator ' . ' known as action prefixing. In the above it signifies that the event open is followed by the event close which in turn leads back to the original state, i.e. Door. We also see how an agent may be given a name. For the purposes of this paper read . . . = . as 'defined to be'. In this case the agent is defined recursively. This need not always be the case. We may want to define agents that perform a sequence of events and then terminate, e.g.: A : : = a.b.Nil Nil is a predefined agent that can perform no actions. Non-deterministic choice is provided by means o f the summation operator ' + '. We could define an agent A to be: A ::= a.b.Nii +c.b.A This agent initially may perform an a or a c. Once the choice is made between the initial events the other initial events are lost. In the above A may do an a followed by a b and then terminate or it may do a c followed by a d and then behave as A. Parallel composition of agents is provided by the ' l ' operator. If A and B are agents then A IB represents the parallel composition of A with B such that each may proceed asynchronously but with the possibility of communication between the agents. In CCS agents communicate or synchronize using a handshake model. Communication may only take place between complementary pairs of events. The complement o f event a is signified by a. In what follows the event a will be taken to denote an input event and its complement an output event. When two or more agents are joined in parallel composition we may wish to 'isolate' complementary events so that they may only be used for synchronization within the composite agent. This is achieved via the restriction operator, ' V . Given two agents: A ::= a.b.A B ::= c.b.B then (AIB)\{b) represents an agent whose events a and c can be observed and use_d for synchronization with other agents. The events b and b can only be used for internal synchronization, and further their occurrence cannot be seen by an external observer. Such private synchronization is represented by the Greek letter r and is called a silent action. The use of to represent communications that are internal to a system and invisible to an observer is particularly important within the calculus. One of our aims when analysing the behaviour
668
of composite systems of agents is, as far as possible, to ignore their internal actions. It often turns out that a sequence of n 1" actions is in some sense equivalent to a single ~'. More will be said about notions of equivalence later in the paper. Before leaving the subject of silent actions and equivalence it is worth pointing out the need to be wary when considering r. To see this consider the following example taken from Milner s. Let: A ::= a.A + r.b.A and
B ::= a.B + b.B If we could always drop r, i.e. if the equation r . X = X were always true, then we would expect A and B to be equivalent. However, close inspection reveals that B always offers a choice between a and b while it is possible for A to evolve silently into a state where only the b event is on offer. This raises questions about equivalence that we will return to below.
I n f o r m a l d e s c r i p t i o n o f the s y s t e m The example we will use is based on the photocopying machine described in Winstanley 6. The machine has two buttons: one to request a copy be made, and the other to switch the machine off. An LCD shows the message 'out of paper' when a sensor on the paper feed-tray detects there is no paper left on attempting to make a copy: paper must then be loaded. At this point in the description of the operation of the copier we have to make a small choice about the subsequent behaviour of our machine. In one scenario we assume that once the paper has been loaded the copy will eventually be produced without the need to repress the copy request button. We also assume a reasonable user who will load paper when requested to do so. An alternative behaviour is to require the copy request button be re-pressed after the paper is loaded thus allowing for a sequence of out of paper messages, i.e. the user need not add paper as requested. We will follow the first scenario. For convenience, although in part due to the limitations of CCS, we assume that the power off button may only be used at the start o f a cycle, i.e. not during the period between the copy request and the production of the copy. We have adopted this constraint on our system because at present CCS does not support an interrupt operator such as the disable operator of LOTOS, although some work has been carried out on a priority choice operator 7, and Milner s gives the semantics for an interrupt operator. It is possible to write a specification that permits a freer use of the power off button; however, the resulting equations would tend to be rather clumsy. Our CCS specification will start with a global view of the behaviour of the photocopier. We will only concern ourselves with the externally observable behaviour of the system. The actions/events of interest are:
event copyreqnest
meaning the depression of the copy button
Information and Software Technology 1994 Volume 36 Number 11
A small CCS case study: I M Bradley producecopy outofpaper paperioaded poweroff
the emergence of a copy the display of the empty paper tray message the replacing of a full paper tray the pressing of the button to switch off the copier
Service specification We start by considering a service specification for the photocopier. A service specification is an abstract description of a system, not dissimilar to a context diagram in structured analysis. We will present two alternative specifications and then consider which is the appropriate version. The first specification represents an intuitive model of the behaviour and the second requires a little more insight into modelling with CCS. In order to improve the readability of the specification we let: PO ::= poweroff.Nil PC ::= producecopy.Photocopierl
(1) (2)
Then the photocopier may be defined as:
Photocopierl ::= copyrequest . (PC + outofpaper.paperloaded.PC) + PO
(3)
We will now determine if this specification represents an adequate model of the machine. Firstly we trace the behaviour of our model by drawing its derivation tree, Figure 1. By looking at the tree it appears, at first glance, that we have a reasonable model. In particular the agent does not deadlock and it will always either terminate following a power off request or return to its initial state. However Equation (3) is of the form: A ::= a.(b.A + c.d.b.A) + e.Nil After an a action we appear to be offered a choice of two
Photocopier 1
events, the output actions b or c. In the case of Photocopierl the choice is between p r o d u c e c o p y or outofpaper. Does this choice really exist? The response to the copyrequest action is determined by the internal state of the copier. The user will observe only one of the responses. The choice between observed events does not exist. We will now produce a second specification designed to show that the response to a copyrequest is determined internally by the photocopier. An observer sees the machine behave in a non-deterministic manner. The definition we arrive at once again uses the agents P O and PC, with Photocopier2 replacing P h o t o c o p i e r l in the defining equation for PC. We have: Photocopier2 ::= copyrequest.PC + copyrequest.outofpaper.paperioaded.PC + PO
(4)
The derivation tree for Photocopier2, Figure 2 shows that we have a specification that exhibits an appropriate behaviour. Equation (4) is of the form:
B ::= a.b.B + a.c.d.b.B + e.Nil After an a action either a b or a c event may occur, the choice being made by agent B according to some hidden logic. An observer cannot predict the outcome of an a experiment. The agent B appears to behave in a nondeterministic manner. We will adopt Photocopier2 for our service specification. A further justification for this decision will be offered below when we attempt to refine our specification and produce an implementation specification.
Implementation specification The service specification obtained above represents a view of the photocopier from a user's view. Other views of the machine are possible. A service engineer may consider the photocopier as consisting of several mechanical subsystems.
Photocopier2
PC + "outotpaI~r.pc~load~l.I~,
~roducecopy
Photocopier 1
~
Nil
u
tofpaper
paperloaded . PC
PC
'outotpaper.lxrperloudedI~C
~oauce=opi~
Photocopier2
paperloaded.PC Iz~rperloadecl
txrI~rloaded PC
PC I
Nil
~roaueecopl~
Photocopier 1 Figure 1 Derivation tree for Photocopierl
Information and Software Technology 1994 Volume36 Number ll
~oroaucecop¥ Photocopier2 Figure 2 Derivation tree for Photocopier2
669
A small CCS case study: I M Bradley
A software engineer designing software to control the photocopier may consider the system as being composed of a set of concurrent processes. Each view demands a more detailed specification that captures the necessary details of the internal behaviour of the system. In this section we will develop the specification of Photocopier2 in terms of possible parallel subsystems. We will call this the 'Implementation Specification'. In simple terms an implementation specification is a refinement of a service specification. Assume that the photocopier consists of two components: an agent Buttons and an agent Tray. The agent Buttons describes the sequence of actions that follow the pushing either of the copy request button or the power off button. Agent T r a y is concerned with providing pages for the copier and the steps required when the paper supply needs replenishing. As with the service specification we will present two possible definitions of the system which we will call PcopierA and PcopierB, and then decide which is the appropriate description of the system. We start by defining an agent ButtonsA.
ButtonsA ::= CopierA + Poweroff
(5)
CopierA represents the actions following the pressing of the copy request button and is defined as: CopierA ::= copyrequest.req.rec.producecopy. ack.ButtonsA
(7)
Finally we define T r a y A to be the agent: TrayA ::= req.rec.ack.TrayA + req.outofpaper. paperioaded.rec.ack.TrayA + done.Nil
(8)
We are now in a position to form our first attempt at an implementation specification for the photocopier in the form of a parallel composition of ButtonsA and T r a y A with the communications via req, rec, ack and done restricted.
PcopierA ::= ( ButtonsA [ Tray A ) \ LA where LA is the set { req,rec,ack,done }
(9)
In arriving at this definition we have followed an intuitive line of reasoning and have placed the non-determinism in the agent TrayA. Although this seems a not unreasonable approach, it is possible to generate an alternative specification. We do this next. This time we will consider a model in which we capture some of the non-determinism in the agent concerned with the copy request button. Let:
670
(10)
where
CopierB ::= copyrequest.BC + copyrequest, nopage.BC
(11)
and BC ::= page.producecopy.ButtonsB
(12)
In Equations (11) and (12) we are using page and nopage to enable CopierB to synchronize with the tray agent which we define as: TrayB ::= page.TrayB + nopage.outofpaper. paperloaded.page.TrayB + done.Nil
(13)
Thus we can now define an alternative implementation for the photocopier:
PcopierB :: = ( ButtonsB I Tray B ) \ LB where LB is the set { page,nopage,done } } (14) An inspection of the derivation trees for PcopierA and PcopierB would show that both agents exhibit acceptable behaviours. We must now address the question of which is 'correct'. In order to do this we must establish some way of measuring how PCopierA and PcopierB relate to Photocopier2. We must consider notions of equivalence.
Analysis for equivalence (6)
After a request for a copy is received the agent asks for a page, via req. Once the page is received, as represented by rec, a copy is produced and the agent sends an acknowledgement ack. The actions ack and rec are used to enable CopierA to synchronize with TrayA. In defining Poweroff we introduce a synchronization event, done, whose function is to enable T r a y A to eventually evolve into the agent Nil. Hence we let:
Poweroff ::= Poweroff.done.Nil
ButtonsB ::= CopierB + Poweroff
The main question we have to consider is 'Can we find a notion of equivalence between agents which captures a satisfactory notion of having the same behaviour?'. In CCS we find several such definitions of equivalence. A full description of each type is outside the scope of this paper. We will concern ourselves with just one, observational equivalence. The notion of observational equivalence can be formally defined. Here we will merely offer an intuitive description. In order that two agents are observationally equivalent we require two properties. Firstly each agent must be capable of performing the same sequences of observable actions. Secondly after each agent evolves from one state to the next as a result of a given observable action the choice of subsequent observable actions should be the same for both agents. The task of showing that PcopierA and PcopierB are observationally equivalent or otherwise to Photocopier2 is a relatively easy task due to the simplicity of the models. We produce a table tracing the actions of each agent pair. In general the task would be non-trivial and tool support is highly desirable. The Concurrency Workbench 8 is just such a software tool. It has been developed for the analysis of finite state CCS expressions. The two most important forms of analysis it can perform are equivalence checking and model checking. In order to help us demonstrate observational equivalence or otherwise, it is convenient to rewrite Equations (9) and (14) removing the parallel composition '[' operators. This rewriting can be carried out by considering the derivation trees. The resulting expressions only involve ' . ' and ' + ' and as such are often easier to follow.
Information and Software Technology 1994 Volume 36 Number 11
A small CCS case study: I M Bradley
The resulting forms for P c o p i e r A and P c o p i e r B are:
Table 2. Testing agents B and C
PeopierA :: = copyrequest. (r.P1 + r.outofpaper.paperloaded.P1) + Poff
a.r.'b.B + a.r.'c.d.r.'b.B+e.r.Nil r.'b.B 'b.B B r.'c.d.r.'b.B 'e.d.r.'b.B d.r.'b.B r.'b.B 'b.B B r.Nil Nil
(15)
and PcopierB ::= copyrequest.P2 + copyrequest.r.outofpaper.paperloaded.P2 + Poff
(16)
where P1 : : = r.producecopy.r.PcopierA P2 : : = r.producecopy.PcopierB Poff :: = poweroff.r.Nil The r represents the silent action o f CCS. As was noted above these represent communications that are internal to a system and are not externally observable. In the analysis that follows we will make the following substitutions in order to make the presentation o f the equivalence tables a little simpler. W e let each o f the observable actions and agents be renamed as copyrequest producecopy outofpaper paperioaded poweroff PcopierA PcopierB Photocopier2
a b c d e A B C
detailed definition o f the system. The 'correctness criteria' between levels of refinement is that each level must be observationally equivalent to the previous one. Before moving to the next stage in the analysis o f the model it is worth making one further point about the choice o f P h o t o c o p i e r 2 for the specification rather than P h o t o c o p i e r l . During the initial work on the model P h o t o c o p i e r l was adopted and an attempt was made to refine the specification. It proved impossible to obtain an implementation specification that was observationally equivalent to Photocopierl.
Analysis using modal logic
Equations (15) and (16) may then be written: A : : = a.( r . r . b . r . A + r . e . d . r . b . r . A ) + e.r.Nil B : : = a.r.b.B + a.r.c.d.r.b.B + e.r.Nil
(17) (18)
and P h o t o c o p i e r 2 may be written as: C : : = a.b.C + a.c.d.b.C + e.Nil
(19)
W e may now present the tables required to show observational equivalence or otherwise. In Table 1 we compare Equations (17) and (19). After the first a action agent A evolves into a state which offers a choice leading to a or a c. The only action available to C after the first a is a b. Hence we conclude that A and C are not observationally equivalent. It is also worth noting that Equation (17) is of the same general form as Equation (3), i.e. after an input it appears to offer the choice between two observable output events. This as we noted above does not represent an appropriate modelling idiom. W e now consider the agents B and C. It can be seen in Table 2 that as each agent enters a new state choice is maintained and so we have observational equivalence between the two. Thus we conclude that the agent P c o p i e r B is the appropriate implementation specification for Photocopier2. Each specification provides a description o f the behaviour o f the photocopier at an appropriate level o f abstraction. If necessary we could refine P c o p i e r B and so obtain a more Table 1. Testing agents A and C a.(r.r.'b.r.A + r.'c.d.r.'b.r.A) + e.r.Nil r.r.'b.r.A + r.'c.d.r.'b.r.A
a.'b.C + a.'c.d.'b.C + e.Nil 'b.C 'b.C C 'c.d.'b.C 'c.d.'b.C d.'b.C 'b.C b.C C Nil Nil
a.'b.C + a.'c.d.'b.C + e.Nil 'b.C
Information and Software Technology 1994 Volume 36 Number 11
The model of the photocopier as represented by Equations (4) and (14) is very simple and most of the desirable properties it should possess are self-evident. Indeed by producing the derivation tree for the system we can check to see if a desired property holds. However, in more complex examples, we may not be able to so readily draw the derivation tree. In such a case we would have to perform some form o f mathematical analysis o f the model in order to establish that the system did exhibit any required properties. In this section we will demonstrate the use of a modal logic as a vehicle to express system properties. The logic we will use is the Hennessey-Milner Logic, (HML) 9. This is a modal logic that is supported within the Concurrency Workbench 8. The Workbench can be used to analyse a model written in CCS in order to determine if the model satisfies a proposition expressed in H M L . W e will begin by briefly introducing H M L . The syntax for the logic can be expressed using a BNF notation as: ,I, : : = tt I~,I, I ,Iq ^ ,I,z I [K]cI, This states that a formula is either the constant formula tt, known as true; or a negative formula ~cI,; or a conjunction of formulas, cI,~ ^ cI,2; or a modalized formula [K] • whose meaning is taken to be cI, holds after every performance o f any action in the set K. Additionally there are several useful operators that may be derived from the above set. The first o f these is < K ) , the dual of [ K ] , which has the meaning after a performance o f an action in the set K. Another two that we will find useful are the disjunction operator, v, and the constant formula if, the negation of tt which is naturally called false. Three abbreviations that we will use below are:
671
A small CCS case study: I M Bradley
H M L above, we define the syntax using a BNF definition:
[an . . . . ,a2] for [{a n. . . . . a2}] [-K] for [ A c t - K ] [-] for [Act] where A c t is the set of all actions available on the given transition system. We denote that an agent P has or satisfies the property 4" by writing P l = 4". We give meaning to tt by noting that all agents satisfy tt, i.e. all P 1= tt, and conversely no agent has the property ft. Using H M L it is possible to express several basic properties that can then be used as building blocks with which to express more complex propositions. The ability to perform an action from the set of actions K is written as (K)tt. The formula [K] ff expresses the inability to perform an action in K. Deadlock is represented by [-] if, i.e. no action can be performed. We can specify the property that an agent must perform a specified action through the formula ( - ) t t A [-a] ft. The first part of this expression affirms that some action is possible, while the second part rules out actions other than a. We will now consider the application of H M L to the agent Photocopier2. What are the properties we would like our agent to exhibit. A starting point might be to ensure that the agent can perform a eopyrequest or a poweroff initially. This is captured by:
Photocopier2 I= (copyrequest,poweroff) tt
(20)
We might also wish to investigate which actions are possible after a copyrequest. It turns out that Photocopier2 satisfies the proposition:
(copyrequest) (poweroff)tt
(21)
but not
[ copyrequest ] (poweroff) tt
(22)
The former expression states that after some copyrequest a p o w e r o f f can occur while the latter represents the proposition that after all copyrequest actions the agent evolves into a state where a p o w e r o f f is possible. An inspection o f Figure 2 shows that after one copyrequest the next event is outofpaper, thus explaining why Photocopier2 does not satisfy proposition Equation (22). Yet another proposition we might wish to confirm is that following the sequence copyrequest, outofpaper the only action available is paperloaded. We capture this using the must idiom:
[copyrequest] (outofpaper)((-)tt A [-paperloadedlff) (23) There is a limit as to how far we can use H M L to express useful propositions. The expressions tend to become lengthy and overly complex very quickly as we try to express 'longer range' properties such as every third action can be a copyrequest. Further certain temporal properties such as 'always' or 'eventually' cannot be expressed in the logic. We need to extend the expressive power of the logic. This we can do via the modal #-calculus.
Using the modal/x-calculus We start by introducing the components of the logic. As with
672
where c~ ranges over actions and Z ranges over variables. The meaning of the expressions defined above is essentially similar to that given for HML. The only new item that requires explanation is vZ.4". This is the greatest fixed point solution of the recursive modal equation Z =4", where Z appears in 4". An intuitive meaning of this can be gained by unfolding the formula, i.e. replacing each occurrence of Z in 4, by vZ.4". The unfolding of vZ is infinite. This can be illustrated in the following example with 4" set equal to q~ A [a] Z, noting that ~b does not contain Z. vZ.cI,. = = = =
vZ.6 A [a]Z 6 A [a] (vZ.6 A [a]Z) 6 ^ [a] (6 a [a] (vZ.6 A [a]Z)) 6 A [a] (6 A [a](6 A [a](vZ.6 A [a]Z)))
From the expansion we find that vZ.~b A [a] Z expresses the property that ~ holds of any process derived from a process P along any execution path of action a. It expresses an invariant property for all a derivatives of a process P. An important derived operator in the calculus is/~Z, the least fixed point solution of the recursive modal equation Z = 4". As with the greatest fixed point an intuitive understanding of the operator can be obtained by unfolding. However, in this case the unfolding is finite. These two operators enable some basic and very useful propositions to be expressed. In particular we can define the following: tt Deadlock__Free Always 6 Possibly 6 Eventually 6 Eventually__Must a
= = = = = =
vZ.Z vZ.(-)tt A [-]Z vZ.6 A [-]Z #Z.6 V (-)Z #Z.6 V ((-)tt A [-]Z) #Z. [-a]Z ^ (-)tt
Using the last of these expressions we can now express the property that 'after a copyrequest the photocopier must eventually execute a produeeeopy':
[eopyrequest ] (#Z. [-produeecopy ] A (-)tt)
(26)
or in a more readable form:
[copyrequest] Eventually__Must producecopy
(27)
Another useful expression we can define ~° is: [L]* = vZ.6 A [ L ] Z which is read as '~b holds now and along all sequences'. Using this expression we can formulate the proposition that 'along any path not involving a p o w e r o f f it is possible to
producecopy': [-poweroff] * Possibly ((producecopy)tt)
(28)
An alternative property we may wish our photocopier to satisfy could be that 'it cannot p r o d u c e c o p y unless a copyrequest has been executed'. We write this as:
[-copyrequest ] * [ producecopy [ff
(29)
With a system as simple as Photocopier2 there are not
Information and Software Technology 1994 Volume 36 Number 11
A small CCS case study: 1 M Bradley
many variations of useful properties we wish to express in the logic and so we will complete the discussion of modal and temporal logic at this point. Hopefully enough has been presented to convince the reader of the potential uses of the two logics. It is worth making one final point at this stage. The verification that the CCS model does satisfy required propositions can be carried out using the Concurrency Workbench. Indeed for more complex models the use of such tool support is probably essential.
Discussion In this paper we have attempted to demonstrate how CCS can be used to specify the behaviour of a concurrent system and how we can check that our CCS model possesses properties we require of the system. A heuristic rule to be used for constructing certain models was initially investigated. It would seem that an expression of the form: a.b.X + a.c.Y is preferable to one of the form
a.(b.X + c.Y) because of the output nature of the events b and c. The choice of response to an a is made internally by the system based on criteria that are hidden in detail from an observer. Using this rule it is possible to produce refinements of the specification for the photocopier that could be shown to be observationally equivalent to the original. It was not possible to do the same when attempting to write the original equations ignoring the guideline. The notion of observational equivalence is central to the 'correctness' of any refinement. However, following the guideline does have a slight drawback in that any model produced may not conform to an 'intuitive' view of a system. Once a system model has been produced it becomes necessary to investigate the properties of the model, e.g. we may wish to ensure that the system does not deadlock. We have shown how these properties may be expressed using the Model ~-Calculus, a temporal logic related to the Hennessey-Milner Logic. The task of verifying these properties is mathematically demanding and software support in the form of the Concurrency Workbench is essential. The example used in the paper is obviously a very simple one. The agent PcopierB only has N states and as such is easily understandable. More realistic problems are highly likely to be much more complex and possess many more states. Burn "~, has produced a CCS model of a rail
lnJbrmation and Software Technology 1994 Volume 36 Number 11
interlocking signalling system which has approximately 3800 states. In another investigation the present author has produced a specification for a system involving a robot, conveyor, index table and a control panel whose implementation specification involved 6400 states. Given systems with this level of complexity (and this is not large in real world problem terms) it is not self-evident that a model will exhibit any of the properties that may be desirable. Yet it is essential that the behaviour of such complex concurrent systems be analysed carefully since at implementation the main problems that occur with such systems often relate to particular timing patterns. The use of CCS combined with the model kt-calculus supported by the Concurrency Workbench provides a means of validating these systems and thus ensuring a correct understanding of their behaviour prior to implementation. The specification and design stages of a project are essentially concerned with modelling a system in order to gain a better understanding of how to obtain some required functionality when the system is implemented. The work described in this paper has demonstrated the use of a formal method and support tools to do just that. One of the main advantages of the approach described here is that although CCS has a sound mathematical base. as have other formal methods, its syntax is simple and a would-be user can learn the notation quite quickly. At the same time the language is sufficiently powerful and expressive to enable the specification of realistic and quite complex systems.
References 1 Simpson, H 'The MASCOT method" IEE/BSC Soft. Eng. J. Vol 1 No 3 (1986) 2 Ward, P and Mellor. S Structured development for real-time systems Prentice-Hall (1985) 3 Gomaa, H 'A software design method for real-time systems" Commun. ACM (1986) 4 Levison, N and Turner, C 'An Investigation of the Therae-25 accidents' IEEE Computer Vol 26 (1993) 5 Milner, R Communication and eoncurrenQ' Prentice-Hall (1989) 6 Winstanley, A C and Bustard, D W 'EXPOSE: an animation tool for process oriented specification' Soft. Eng. J. (1991). 7 Camilleri, J 'CCS with prioritychoice' Proc. 6th Ann. IEEE Svmp. on Logic in Computer Science (1991) 8 Cleaveland. R, Parrow, J and Steffen, B 'The concurrency work bench: a semantics-based verification tool for finite state systems"
Proc. of the Workshop on Automated Verification Methods for Finitestate Systems, Lecture Notes in Computer Science 407 Springer-Verlag (1989). 9 Stirling, C 'An introduction to modal and temporal logics for CCS' Springer- Verlag Lecture Notes in Computer Science 491 ( 1991 ) 10 Burns. G 'A case study in safety-critical design' LFCS Report. University of Edinburgh (1992)
673
The formal specification of concurrent systems: a small CCS case study I M Bradley Department of Computing, University of Northumbria at Newcastle, Newcastle upon Tyne NE1 8ST, UK
Building complex, concurrent systems requires a large amount of care. Such systems often have many interactions between components. Some of the more obscure timing patterns can lead eventually to system failure. It is essential that any problems be identified as soon as possible in the life of a project. This short paper is intended to demonstrate how the behaviour of a concurrent system can be specified using CCS. Various models of the system are presented and discussed. We show how having developed a 'black box' specification of a system it may be refined and that refinement verified against the original specification. Finally we show how modal and temporal logic may be used to express desirable properties of the system. Keywords: formal specification, CCS, process algebra, modal logic, concurrent systems, temporal logic
It is widely recognized that the requirements specification for a system can be vital for the successful development of that system. Concurrent systems provide a particularly difficult area for specification because of the potentially complex interactions that can exist between the system components. Yet because many concurrent systems also exhibit real-time requirements and may be safety critical their correct specification is of particular importance. For many years so-called structured methods, such as MASCOT ~, RTSA 2 and DARTS 3 have been used to build requirements models of concurrent real-time systems. Although these methods provide a vehicle for analysing concurrent systems they are deficient in several aspects. Firstly because they are not firmly based in mathematics there is no formal proof obligation between levels of refinement that are identified during the analysis stage. Further there is no method of proving that the structured specification captures the desired properties of the systems. In the case of real-time safety critical systems these may be absolutely essential safety requirements. If the absence of such properties is not detected at an early stage in the project, i.e. at the specification stage, expensive rework of the project can result. If the omission of such properties is not detected until after implementation then the results could be catastrophic. An example of such a development was the case of Therac-254. This system, designed to provide radiation therapy, failed as a result of software errors, with the result that several patients died and others received large unsafe doses of radiation.
0950-5849/94/011667--07 © 1994 Butterworth-Heinemann Ltd
In this paper we will present a short case study intended to demonstrate how we may use formal methods, and in particular CCS 5, to capture the requirements and model the behaviour of concurrent systems. We begin by presenting a short introduction to CCS: this is followed by the development of the specification for the example that is the subject of the case study; and some modelling issues will be discussed. Finally we will show how a modal and temporal logic can be used to represent the desired features of our system and explain how these representations can be used, with software support, to help validate the specification.
Overview of CCS The Calculus of Communicating Systems, CCS, belongs to the set of formal methods known as process algebras. It models concurrency in terms of communicating processes, discrete events, asynchronous execution, and handshake communication. A CCS model consists of a set of agents (processes), and events (actions). Events are regarded as atomic actions indivisible with time. In the following we will provide a short basic introduction to CCS. It is not the intention to present a full description of the semantics of the method but rather to enable the reader to follow the specification presented in the main part of the paper. A fuller description of CCS can be found in Milner 5. In CCS we could model a door which can open and close as:
667
A small CCS case study." 1 M Bradley
Door:: = open.close.Door This definition defines an agent D o o r that first performs the action open, then the action close and then behaves as a Door, i.e. it represents a door that can continually open and then close. This definition introduces several features o f CCS. First we note some simple syntactic conventions. The names of agents must start with a capital letter and the names of events must start with lower case letters. The definition introduces the sequential operator ' . ' known as action prefixing. In the above it signifies that the event open is followed by the event close which in turn leads back to the original state, i.e. Door. We also see how an agent may be given a name. For the purposes of this paper read . . . = . as 'defined to be'. In this case the agent is defined recursively. This need not always be the case. We may want to define agents that perform a sequence of events and then terminate, e.g.: A : : = a.b.Nil Nil is a predefined agent that can perform no actions. Non-deterministic choice is provided by means o f the summation operator ' + '. We could define an agent A to be: A ::= a.b.Nii +c.b.A This agent initially may perform an a or a c. Once the choice is made between the initial events the other initial events are lost. In the above A may do an a followed by a b and then terminate or it may do a c followed by a d and then behave as A. Parallel composition of agents is provided by the ' l ' operator. If A and B are agents then A IB represents the parallel composition of A with B such that each may proceed asynchronously but with the possibility of communication between the agents. In CCS agents communicate or synchronize using a handshake model. Communication may only take place between complementary pairs of events. The complement o f event a is signified by a. In what follows the event a will be taken to denote an input event and its complement an output event. When two or more agents are joined in parallel composition we may wish to 'isolate' complementary events so that they may only be used for synchronization within the composite agent. This is achieved via the restriction operator, ' V . Given two agents: A ::= a.b.A B ::= c.b.B then (AIB)\{b) represents an agent whose events a and c can be observed and use_d for synchronization with other agents. The events b and b can only be used for internal synchronization, and further their occurrence cannot be seen by an external observer. Such private synchronization is represented by the Greek letter r and is called a silent action. The use of to represent communications that are internal to a system and invisible to an observer is particularly important within the calculus. One of our aims when analysing the behaviour
668
of composite systems of agents is, as far as possible, to ignore their internal actions. It often turns out that a sequence of n 1" actions is in some sense equivalent to a single ~'. More will be said about notions of equivalence later in the paper. Before leaving the subject of silent actions and equivalence it is worth pointing out the need to be wary when considering r. To see this consider the following example taken from Milner s. Let: A ::= a.A + r.b.A and
B ::= a.B + b.B If we could always drop r, i.e. if the equation r . X = X were always true, then we would expect A and B to be equivalent. However, close inspection reveals that B always offers a choice between a and b while it is possible for A to evolve silently into a state where only the b event is on offer. This raises questions about equivalence that we will return to below.
I n f o r m a l d e s c r i p t i o n o f the s y s t e m The example we will use is based on the photocopying machine described in Winstanley 6. The machine has two buttons: one to request a copy be made, and the other to switch the machine off. An LCD shows the message 'out of paper' when a sensor on the paper feed-tray detects there is no paper left on attempting to make a copy: paper must then be loaded. At this point in the description of the operation of the copier we have to make a small choice about the subsequent behaviour of our machine. In one scenario we assume that once the paper has been loaded the copy will eventually be produced without the need to repress the copy request button. We also assume a reasonable user who will load paper when requested to do so. An alternative behaviour is to require the copy request button be re-pressed after the paper is loaded thus allowing for a sequence of out of paper messages, i.e. the user need not add paper as requested. We will follow the first scenario. For convenience, although in part due to the limitations of CCS, we assume that the power off button may only be used at the start o f a cycle, i.e. not during the period between the copy request and the production of the copy. We have adopted this constraint on our system because at present CCS does not support an interrupt operator such as the disable operator of LOTOS, although some work has been carried out on a priority choice operator 7, and Milner s gives the semantics for an interrupt operator. It is possible to write a specification that permits a freer use of the power off button; however, the resulting equations would tend to be rather clumsy. Our CCS specification will start with a global view of the behaviour of the photocopier. We will only concern ourselves with the externally observable behaviour of the system. The actions/events of interest are:
event copyreqnest
meaning the depression of the copy button
Information and Software Technology 1994 Volume 36 Number 11
A small CCS case study: I M Bradley producecopy outofpaper paperioaded poweroff
the emergence of a copy the display of the empty paper tray message the replacing of a full paper tray the pressing of the button to switch off the copier
Service specification We start by considering a service specification for the photocopier. A service specification is an abstract description of a system, not dissimilar to a context diagram in structured analysis. We will present two alternative specifications and then consider which is the appropriate version. The first specification represents an intuitive model of the behaviour and the second requires a little more insight into modelling with CCS. In order to improve the readability of the specification we let: PO ::= poweroff.Nil PC ::= producecopy.Photocopierl
(1) (2)
Then the photocopier may be defined as:
Photocopierl ::= copyrequest . (PC + outofpaper.paperloaded.PC) + PO
(3)
We will now determine if this specification represents an adequate model of the machine. Firstly we trace the behaviour of our model by drawing its derivation tree, Figure 1. By looking at the tree it appears, at first glance, that we have a reasonable model. In particular the agent does not deadlock and it will always either terminate following a power off request or return to its initial state. However Equation (3) is of the form: A ::= a.(b.A + c.d.b.A) + e.Nil After an a action we appear to be offered a choice of two
Photocopier 1
events, the output actions b or c. In the case of Photocopierl the choice is between p r o d u c e c o p y or outofpaper. Does this choice really exist? The response to the copyrequest action is determined by the internal state of the copier. The user will observe only one of the responses. The choice between observed events does not exist. We will now produce a second specification designed to show that the response to a copyrequest is determined internally by the photocopier. An observer sees the machine behave in a non-deterministic manner. The definition we arrive at once again uses the agents P O and PC, with Photocopier2 replacing P h o t o c o p i e r l in the defining equation for PC. We have: Photocopier2 ::= copyrequest.PC + copyrequest.outofpaper.paperioaded.PC + PO
(4)
The derivation tree for Photocopier2, Figure 2 shows that we have a specification that exhibits an appropriate behaviour. Equation (4) is of the form:
B ::= a.b.B + a.c.d.b.B + e.Nil After an a action either a b or a c event may occur, the choice being made by agent B according to some hidden logic. An observer cannot predict the outcome of an a experiment. The agent B appears to behave in a nondeterministic manner. We will adopt Photocopier2 for our service specification. A further justification for this decision will be offered below when we attempt to refine our specification and produce an implementation specification.
Implementation specification The service specification obtained above represents a view of the photocopier from a user's view. Other views of the machine are possible. A service engineer may consider the photocopier as consisting of several mechanical subsystems.
Photocopier2
PC + "outotpaI~r.pc~load~l.I~,
~roducecopy
Photocopier 1
~
Nil
u
tofpaper
paperloaded . PC
PC
'outotpaper.lxrperloudedI~C
~oauce=opi~
Photocopier2
paperloaded.PC Iz~rperloadecl
txrI~rloaded PC
PC I
Nil
~roaueecopl~
Photocopier 1 Figure 1 Derivation tree for Photocopierl
Information and Software Technology 1994 Volume36 Number ll
~oroaucecop¥ Photocopier2 Figure 2 Derivation tree for Photocopier2
669
A small CCS case study: I M Bradley
A software engineer designing software to control the photocopier may consider the system as being composed of a set of concurrent processes. Each view demands a more detailed specification that captures the necessary details of the internal behaviour of the system. In this section we will develop the specification of Photocopier2 in terms of possible parallel subsystems. We will call this the 'Implementation Specification'. In simple terms an implementation specification is a refinement of a service specification. Assume that the photocopier consists of two components: an agent Buttons and an agent Tray. The agent Buttons describes the sequence of actions that follow the pushing either of the copy request button or the power off button. Agent T r a y is concerned with providing pages for the copier and the steps required when the paper supply needs replenishing. As with the service specification we will present two possible definitions of the system which we will call PcopierA and PcopierB, and then decide which is the appropriate description of the system. We start by defining an agent ButtonsA.
ButtonsA ::= CopierA + Poweroff
(5)
CopierA represents the actions following the pressing of the copy request button and is defined as: CopierA ::= copyrequest.req.rec.producecopy. ack.ButtonsA
(7)
Finally we define T r a y A to be the agent: TrayA ::= req.rec.ack.TrayA + req.outofpaper. paperioaded.rec.ack.TrayA + done.Nil
(8)
We are now in a position to form our first attempt at an implementation specification for the photocopier in the form of a parallel composition of ButtonsA and T r a y A with the communications via req, rec, ack and done restricted.
PcopierA ::= ( ButtonsA [ Tray A ) \ LA where LA is the set { req,rec,ack,done }
(9)
In arriving at this definition we have followed an intuitive line of reasoning and have placed the non-determinism in the agent TrayA. Although this seems a not unreasonable approach, it is possible to generate an alternative specification. We do this next. This time we will consider a model in which we capture some of the non-determinism in the agent concerned with the copy request button. Let:
670
(10)
where
CopierB ::= copyrequest.BC + copyrequest, nopage.BC
(11)
and BC ::= page.producecopy.ButtonsB
(12)
In Equations (11) and (12) we are using page and nopage to enable CopierB to synchronize with the tray agent which we define as: TrayB ::= page.TrayB + nopage.outofpaper. paperloaded.page.TrayB + done.Nil
(13)
Thus we can now define an alternative implementation for the photocopier:
PcopierB :: = ( ButtonsB I Tray B ) \ LB where LB is the set { page,nopage,done } } (14) An inspection of the derivation trees for PcopierA and PcopierB would show that both agents exhibit acceptable behaviours. We must now address the question of which is 'correct'. In order to do this we must establish some way of measuring how PCopierA and PcopierB relate to Photocopier2. We must consider notions of equivalence.
Analysis for equivalence (6)
After a request for a copy is received the agent asks for a page, via req. Once the page is received, as represented by rec, a copy is produced and the agent sends an acknowledgement ack. The actions ack and rec are used to enable CopierA to synchronize with TrayA. In defining Poweroff we introduce a synchronization event, done, whose function is to enable T r a y A to eventually evolve into the agent Nil. Hence we let:
Poweroff ::= Poweroff.done.Nil
ButtonsB ::= CopierB + Poweroff
The main question we have to consider is 'Can we find a notion of equivalence between agents which captures a satisfactory notion of having the same behaviour?'. In CCS we find several such definitions of equivalence. A full description of each type is outside the scope of this paper. We will concern ourselves with just one, observational equivalence. The notion of observational equivalence can be formally defined. Here we will merely offer an intuitive description. In order that two agents are observationally equivalent we require two properties. Firstly each agent must be capable of performing the same sequences of observable actions. Secondly after each agent evolves from one state to the next as a result of a given observable action the choice of subsequent observable actions should be the same for both agents. The task of showing that PcopierA and PcopierB are observationally equivalent or otherwise to Photocopier2 is a relatively easy task due to the simplicity of the models. We produce a table tracing the actions of each agent pair. In general the task would be non-trivial and tool support is highly desirable. The Concurrency Workbench 8 is just such a software tool. It has been developed for the analysis of finite state CCS expressions. The two most important forms of analysis it can perform are equivalence checking and model checking. In order to help us demonstrate observational equivalence or otherwise, it is convenient to rewrite Equations (9) and (14) removing the parallel composition '[' operators. This rewriting can be carried out by considering the derivation trees. The resulting expressions only involve ' . ' and ' + ' and as such are often easier to follow.
Information and Software Technology 1994 Volume 36 Number 11
A small CCS case study: I M Bradley
The resulting forms for P c o p i e r A and P c o p i e r B are:
Table 2. Testing agents B and C
PeopierA :: = copyrequest. (r.P1 + r.outofpaper.paperloaded.P1) + Poff
a.r.'b.B + a.r.'c.d.r.'b.B+e.r.Nil r.'b.B 'b.B B r.'c.d.r.'b.B 'e.d.r.'b.B d.r.'b.B r.'b.B 'b.B B r.Nil Nil
(15)
and PcopierB ::= copyrequest.P2 + copyrequest.r.outofpaper.paperloaded.P2 + Poff
(16)
where P1 : : = r.producecopy.r.PcopierA P2 : : = r.producecopy.PcopierB Poff :: = poweroff.r.Nil The r represents the silent action o f CCS. As was noted above these represent communications that are internal to a system and are not externally observable. In the analysis that follows we will make the following substitutions in order to make the presentation o f the equivalence tables a little simpler. W e let each o f the observable actions and agents be renamed as copyrequest producecopy outofpaper paperioaded poweroff PcopierA PcopierB Photocopier2
a b c d e A B C
detailed definition o f the system. The 'correctness criteria' between levels of refinement is that each level must be observationally equivalent to the previous one. Before moving to the next stage in the analysis o f the model it is worth making one further point about the choice o f P h o t o c o p i e r 2 for the specification rather than P h o t o c o p i e r l . During the initial work on the model P h o t o c o p i e r l was adopted and an attempt was made to refine the specification. It proved impossible to obtain an implementation specification that was observationally equivalent to Photocopierl.
Analysis using modal logic
Equations (15) and (16) may then be written: A : : = a.( r . r . b . r . A + r . e . d . r . b . r . A ) + e.r.Nil B : : = a.r.b.B + a.r.c.d.r.b.B + e.r.Nil
(17) (18)
and P h o t o c o p i e r 2 may be written as: C : : = a.b.C + a.c.d.b.C + e.Nil
(19)
W e may now present the tables required to show observational equivalence or otherwise. In Table 1 we compare Equations (17) and (19). After the first a action agent A evolves into a state which offers a choice leading to a or a c. The only action available to C after the first a is a b. Hence we conclude that A and C are not observationally equivalent. It is also worth noting that Equation (17) is of the same general form as Equation (3), i.e. after an input it appears to offer the choice between two observable output events. This as we noted above does not represent an appropriate modelling idiom. W e now consider the agents B and C. It can be seen in Table 2 that as each agent enters a new state choice is maintained and so we have observational equivalence between the two. Thus we conclude that the agent P c o p i e r B is the appropriate implementation specification for Photocopier2. Each specification provides a description o f the behaviour o f the photocopier at an appropriate level o f abstraction. If necessary we could refine P c o p i e r B and so obtain a more Table 1. Testing agents A and C a.(r.r.'b.r.A + r.'c.d.r.'b.r.A) + e.r.Nil r.r.'b.r.A + r.'c.d.r.'b.r.A
a.'b.C + a.'c.d.'b.C + e.Nil 'b.C 'b.C C 'c.d.'b.C 'c.d.'b.C d.'b.C 'b.C b.C C Nil Nil
a.'b.C + a.'c.d.'b.C + e.Nil 'b.C
Information and Software Technology 1994 Volume 36 Number 11
The model of the photocopier as represented by Equations (4) and (14) is very simple and most of the desirable properties it should possess are self-evident. Indeed by producing the derivation tree for the system we can check to see if a desired property holds. However, in more complex examples, we may not be able to so readily draw the derivation tree. In such a case we would have to perform some form o f mathematical analysis o f the model in order to establish that the system did exhibit any required properties. In this section we will demonstrate the use of a modal logic as a vehicle to express system properties. The logic we will use is the Hennessey-Milner Logic, (HML) 9. This is a modal logic that is supported within the Concurrency Workbench 8. The Workbench can be used to analyse a model written in CCS in order to determine if the model satisfies a proposition expressed in H M L . W e will begin by briefly introducing H M L . The syntax for the logic can be expressed using a BNF notation as: ,I, : : = tt I~,I, I ,Iq ^ ,I,z I [K]cI, This states that a formula is either the constant formula tt, known as true; or a negative formula ~cI,; or a conjunction of formulas, cI,~ ^ cI,2; or a modalized formula [K] • whose meaning is taken to be cI, holds after every performance o f any action in the set K. Additionally there are several useful operators that may be derived from the above set. The first o f these is < K ) , the dual of [ K ] , which has the meaning after a performance o f an action in the set K. Another two that we will find useful are the disjunction operator, v, and the constant formula if, the negation of tt which is naturally called false. Three abbreviations that we will use below are:
671
A small CCS case study: I M Bradley
H M L above, we define the syntax using a BNF definition:
[an . . . . ,a2] for [{a n. . . . . a2}] [-K] for [ A c t - K ] [-] for [Act] where A c t is the set of all actions available on the given transition system. We denote that an agent P has or satisfies the property 4" by writing P l = 4". We give meaning to tt by noting that all agents satisfy tt, i.e. all P 1= tt, and conversely no agent has the property ft. Using H M L it is possible to express several basic properties that can then be used as building blocks with which to express more complex propositions. The ability to perform an action from the set of actions K is written as (K)tt. The formula [K] ff expresses the inability to perform an action in K. Deadlock is represented by [-] if, i.e. no action can be performed. We can specify the property that an agent must perform a specified action through the formula ( - ) t t A [-a] ft. The first part of this expression affirms that some action is possible, while the second part rules out actions other than a. We will now consider the application of H M L to the agent Photocopier2. What are the properties we would like our agent to exhibit. A starting point might be to ensure that the agent can perform a eopyrequest or a poweroff initially. This is captured by:
Photocopier2 I= (copyrequest,poweroff) tt
(20)
We might also wish to investigate which actions are possible after a copyrequest. It turns out that Photocopier2 satisfies the proposition:
(copyrequest) (poweroff)tt
(21)
but not
[ copyrequest ] (poweroff) tt
(22)
The former expression states that after some copyrequest a p o w e r o f f can occur while the latter represents the proposition that after all copyrequest actions the agent evolves into a state where a p o w e r o f f is possible. An inspection o f Figure 2 shows that after one copyrequest the next event is outofpaper, thus explaining why Photocopier2 does not satisfy proposition Equation (22). Yet another proposition we might wish to confirm is that following the sequence copyrequest, outofpaper the only action available is paperloaded. We capture this using the must idiom:
[copyrequest] (outofpaper)((-)tt A [-paperloadedlff) (23) There is a limit as to how far we can use H M L to express useful propositions. The expressions tend to become lengthy and overly complex very quickly as we try to express 'longer range' properties such as every third action can be a copyrequest. Further certain temporal properties such as 'always' or 'eventually' cannot be expressed in the logic. We need to extend the expressive power of the logic. This we can do via the modal #-calculus.
Using the modal/x-calculus We start by introducing the components of the logic. As with
672
where c~ ranges over actions and Z ranges over variables. The meaning of the expressions defined above is essentially similar to that given for HML. The only new item that requires explanation is vZ.4". This is the greatest fixed point solution of the recursive modal equation Z =4", where Z appears in 4". An intuitive meaning of this can be gained by unfolding the formula, i.e. replacing each occurrence of Z in 4, by vZ.4". The unfolding of vZ is infinite. This can be illustrated in the following example with 4" set equal to q~ A [a] Z, noting that ~b does not contain Z. vZ.cI,. = = = =
vZ.6 A [a]Z 6 A [a] (vZ.6 A [a]Z) 6 ^ [a] (6 a [a] (vZ.6 A [a]Z)) 6 A [a] (6 A [a](6 A [a](vZ.6 A [a]Z)))
From the expansion we find that vZ.~b A [a] Z expresses the property that ~ holds of any process derived from a process P along any execution path of action a. It expresses an invariant property for all a derivatives of a process P. An important derived operator in the calculus is/~Z, the least fixed point solution of the recursive modal equation Z = 4". As with the greatest fixed point an intuitive understanding of the operator can be obtained by unfolding. However, in this case the unfolding is finite. These two operators enable some basic and very useful propositions to be expressed. In particular we can define the following: tt Deadlock__Free Always 6 Possibly 6 Eventually 6 Eventually__Must a
= = = = = =
vZ.Z vZ.(-)tt A [-]Z vZ.6 A [-]Z #Z.6 V (-)Z #Z.6 V ((-)tt A [-]Z) #Z. [-a]Z ^ (-)tt
Using the last of these expressions we can now express the property that 'after a copyrequest the photocopier must eventually execute a produeeeopy':
[eopyrequest ] (#Z. [-produeecopy ] A (-)tt)
(26)
or in a more readable form:
[copyrequest] Eventually__Must producecopy
(27)
Another useful expression we can define ~° is: [L]* = vZ.6 A [ L ] Z which is read as '~b holds now and along all sequences'. Using this expression we can formulate the proposition that 'along any path not involving a p o w e r o f f it is possible to
producecopy': [-poweroff] * Possibly ((producecopy)tt)
(28)
An alternative property we may wish our photocopier to satisfy could be that 'it cannot p r o d u c e c o p y unless a copyrequest has been executed'. We write this as:
[-copyrequest ] * [ producecopy [ff
(29)
With a system as simple as Photocopier2 there are not
Information and Software Technology 1994 Volume 36 Number 11
A small CCS case study: 1 M Bradley
many variations of useful properties we wish to express in the logic and so we will complete the discussion of modal and temporal logic at this point. Hopefully enough has been presented to convince the reader of the potential uses of the two logics. It is worth making one final point at this stage. The verification that the CCS model does satisfy required propositions can be carried out using the Concurrency Workbench. Indeed for more complex models the use of such tool support is probably essential.
Discussion In this paper we have attempted to demonstrate how CCS can be used to specify the behaviour of a concurrent system and how we can check that our CCS model possesses properties we require of the system. A heuristic rule to be used for constructing certain models was initially investigated. It would seem that an expression of the form: a.b.X + a.c.Y is preferable to one of the form
a.(b.X + c.Y) because of the output nature of the events b and c. The choice of response to an a is made internally by the system based on criteria that are hidden in detail from an observer. Using this rule it is possible to produce refinements of the specification for the photocopier that could be shown to be observationally equivalent to the original. It was not possible to do the same when attempting to write the original equations ignoring the guideline. The notion of observational equivalence is central to the 'correctness' of any refinement. However, following the guideline does have a slight drawback in that any model produced may not conform to an 'intuitive' view of a system. Once a system model has been produced it becomes necessary to investigate the properties of the model, e.g. we may wish to ensure that the system does not deadlock. We have shown how these properties may be expressed using the Model ~-Calculus, a temporal logic related to the Hennessey-Milner Logic. The task of verifying these properties is mathematically demanding and software support in the form of the Concurrency Workbench is essential. The example used in the paper is obviously a very simple one. The agent PcopierB only has N states and as such is easily understandable. More realistic problems are highly likely to be much more complex and possess many more states. Burn "~, has produced a CCS model of a rail
lnJbrmation and Software Technology 1994 Volume 36 Number 11
interlocking signalling system which has approximately 3800 states. In another investigation the present author has produced a specification for a system involving a robot, conveyor, index table and a control panel whose implementation specification involved 6400 states. Given systems with this level of complexity (and this is not large in real world problem terms) it is not self-evident that a model will exhibit any of the properties that may be desirable. Yet it is essential that the behaviour of such complex concurrent systems be analysed carefully since at implementation the main problems that occur with such systems often relate to particular timing patterns. The use of CCS combined with the model kt-calculus supported by the Concurrency Workbench provides a means of validating these systems and thus ensuring a correct understanding of their behaviour prior to implementation. The specification and design stages of a project are essentially concerned with modelling a system in order to gain a better understanding of how to obtain some required functionality when the system is implemented. The work described in this paper has demonstrated the use of a formal method and support tools to do just that. One of the main advantages of the approach described here is that although CCS has a sound mathematical base. as have other formal methods, its syntax is simple and a would-be user can learn the notation quite quickly. At the same time the language is sufficiently powerful and expressive to enable the specification of realistic and quite complex systems.
References 1 Simpson, H 'The MASCOT method" IEE/BSC Soft. Eng. J. Vol 1 No 3 (1986) 2 Ward, P and Mellor. S Structured development for real-time systems Prentice-Hall (1985) 3 Gomaa, H 'A software design method for real-time systems" Commun. ACM (1986) 4 Levison, N and Turner, C 'An Investigation of the Therae-25 accidents' IEEE Computer Vol 26 (1993) 5 Milner, R Communication and eoncurrenQ' Prentice-Hall (1989) 6 Winstanley, A C and Bustard, D W 'EXPOSE: an animation tool for process oriented specification' Soft. Eng. J. (1991). 7 Camilleri, J 'CCS with prioritychoice' Proc. 6th Ann. IEEE Svmp. on Logic in Computer Science (1991) 8 Cleaveland. R, Parrow, J and Steffen, B 'The concurrency work bench: a semantics-based verification tool for finite state systems"
Proc. of the Workshop on Automated Verification Methods for Finitestate Systems, Lecture Notes in Computer Science 407 Springer-Verlag (1989). 9 Stirling, C 'An introduction to modal and temporal logics for CCS' Springer- Verlag Lecture Notes in Computer Science 491 ( 1991 ) 10 Burns. G 'A case study in safety-critical design' LFCS Report. University of Edinburgh (1992)
673