GB2465382A - Method of producing computer programs - Google Patents

Abstract

The present invention relates to a method for producing a computer program comprising the steps of storing a plurality of first computer programs in a memory, selecting at least some of said first computer programs and generating a plurality of second computer programs based upon said selected first computer programs and selecting at least one of the sais programs. The selection of the first programs is based upon testing of each of said first computer programs for predetermined functionality, and analysis of at least one formal property of each of the first computer programs. The formal property may preferably one of resource consumption, deadlock probability or the number of operations, flows or variables. The programs may be represented by a petri net. The second programs maybe generated using genetic programming techniques such as mutation, reproduction or recombination. The second program is preferably selected by generating a value for each of the formal properties and combining them as a score which can then be weighted. In a particular embodiment the method is used to generate and select a program to implement a communications protocol.

Description

PROGRAMMING METHOD

The present invention relates to a method for producing computer programs. The method has particular, but not exclusive, application in the evolution of computer programs arranged to implement a network protocol.

Evolutionary, or genetic, programming is an approach that seeks to search the space of all possible solutions to a given programming problem. Generally, the programming problems under consideration concern systems, such as Medium Access Control (MAC) modules, that can be functionally tested using black box' testing methods. Black box testing involves observing outputs generated by a system in response to specific inputs, and determining if those outputs correspond to expected outputs for the provided inputs.

Using genetic programming, a candidate program is evolved from a set of program elements, which, when executed provide a candidate solution to the problem at hand.

The candidate programs may be thought of as parse trees. For example when evolving expressions, a simple candidate program a + (b * c)' can be described in parse tree form as: + / \ a * / \ b c In parse tree terminology, the leaves of the tree are known as terminals, while the nodes with children are known as functions. A function's children provide the argument of that function. A set of rules (known as a grammar) describes how candidate programs can be built from a set of available functions and terminals that are appropriate to solving problems of the type being considered, and how candidate programs can be divided and/or joined to make new candidate programs.

An initial population of candidate programs is randomly generated according to the rules. Each candidate program is then tested using a set of functional tests to determine the fitness of that candidate program to solve the given problem. A fitness function is arranged to provide a score indicative of the fitness of a program candidate, based upon the functional tests. The fittest candidate programs from the set as determined by applying the fitness function are then used as the basis for the next generation of candidate programs, such that over a number of generations, successively fitter candidate programs are evolved.

A new generation of candidate programs may be created via reproduction (wherein a program is wholly copied exactly), mutation (wherein a program is wholly copied with random variations, for example, a random replacement of a sub-tree with a function, the random replacement of terminals, the random definition of terminals with values, or variation of terminal values), or recombination (wherein a sub-tree from one program is replaced with a sub-tree randomly selected from another program).

The newly evolved generation of candidate programs is then evaluated using the fitness function and the fittest candidate programs of that generation are used as the basis for evolution of the next generation. Generally, the process iterates for a defined number of generations, or until at least one candidate program achieves a desired fitness.

Genetic programming has been applied to a number of applications, including improving the performance of the Distributed Coordination Function of the IEEE 802.11 protocol.

While such solutions can improve the design of programs and protocols in an "off-line" environment, the time taken to evolve programs in the manner described above generally precludes "on-line", or real-time use of genetic programming techniques to generate or adapt programs and protocols to specific environments and uses. For example, where two devices wish to communicate using the IEEE 802.11 protocol, it is typically unacceptable for those devices to wait until the evolution process has completed before they can begin transmitting data to each other, particularly given the limited processing resources available to some classes of portable device, such as cell phones.

It is an object of embodiments of the present invention to obviate or mitigate at least some of the problems identified above.

According to the present invention, there is provided, a method for producing a computer program. The method comprises storing a plurality of first computer programs in a memory; selecting at least some of said first computer programs, generating a plurality of second computer programs based upon said selected computer programs; and selecting at least one of said second computer programs. The selecting of the first computer programs is based upon testing of each of said first computer programs for predetermined functionality, and analysis of at least one formal property of each of the first computer programs.

The present invention therefore provides a method which allows first computer programs which are to be used as a basis for generation of second computer programs to be selected not only based upon functional tests, but also on the basis of formal analysis.

The use of formal analysis allows first computer programs to be more effectively selected, and can result in more efficient generation of computer programs which better satisfy particular requirements. This will typically allow a computer program providing required functionality to be more quickly identified.

A formal property is a property of an algorithm which can be derived mathematically and formally verified using formal mathematical methods. Generally, a formal property can be mathematically proven, through static analysis (not execution) of a representation of the algorithm, to hold for all possible executions of the algorithm.

The plurality of second computer programs may be generated using genetic programming techniques, which may comprise at least one of mutation, reproduction and recombination. Scores associated with the first computer programs may be generated by appropriately defined fitness functions.

Selecting at least one of said second programs may comprise generating a score for each of said plurality of second computer programs. Each of said scores may be based upon testing of a respective second computer program for predetermined fimetionality, and analysis of at least one formal property of the respective second computer program.

The at least one formal property may be a plurality of formal properties. The method may further comprise generating a value associated with each of said plurality of formal properties and combining said values to generate said score. Combining said values may comprise combining said values in accordance with predetermined weights.

The at least one formal property may be selected from the group consisting of properties indicative of resource consumption, ability to deadlock and number of operations.

Each first computer program may be represented by a respective Petri net. Generating a plurality of second computer programs based upon said selected computer programs may comprise generating Petri nets representing each of said plurality of second computer programs. The term Petri net includes all high-order/ extended Petri nets, for example, coloured, stochastic, fluid or timed Petri nets andl or any combination of these.

Selecting at least some of said first computer programs may comprise generating a first score for each first computer program based upon analysis of at least one formal property of a respective first computer program; and generating a second score for a subset of said first computer programs, said second score being based upon testing of a respective computer program for predetermined functionality, and said subset being selected based upon said first scores. Selecting of said first computer programs may be based upon said second scores.

Selecting at least some of said first computer programs may comprise for each computer program selected based upon said second scores, generating a third score based upon analysis of at least one formal property of computer programs selected based upon said second scores.

Testing a respective computer program for predetermined functionality may comprise applying at least one predetermined input to said computer program and processing at least one output generated by said computer program in response to said at least one predetermined input to determine whether said at least one output satisfies a predetermined criterion. Processing at least one output generated by said computer program in response to said at least one predetermined input to determine whether said at least one output satisfies a predetermined criterion may comprise determining whether a predetermined output sequence is generated by said computer program.

The plurality of first computer programs may be generated by combining terms of a predetermined set of terms in accordance with a predetermined grammar.

The generated computer program may be arranged to implement a communications protocol. Said computer program may be arranged to implement at least one layer of a protocol stack. The communications protocol may be a medium access control protocol.

The method may further comprise providing the generated computer program to at least one further computing device.

The invention also provides a method of generating an implementation of a communications protocol, the method comprising generating a computer program providing first functionality defined by said communications protocol at a first computing device using a method as described above, and generating a computer program providing second functionality defined by said communications protocol at a second computing device using a method as described above.

Said computer program providing first functionality and said computer program providing second functionality may be arranged to allow communication between said first and second computing devices.

The method may further comprise providing said computer program providing first functionality to said second computing device and providing said computer program providing second functionality to said first computing device.

The first functionality may be transmission functionality and the second functionality may be reception functionality.

Aspects of the invention also provide computer programs arranged to carry out the methods described above. The computer programs may be carried on suitable carrier media which may be tangible media (e.g. disks) or intangible media (e.g. communications signals). Aspects of the invention further provide apparatus arranged to carry out the method described above. Such apparatus include general purpose computing devices running computer programs arranged to carry out the described methods.

Embodiments of the present invention are now described, by way of example, with reference to the accompanying drawings, in which: Figure 1 is a high level schematic illustration of an genetic programming arrangement

known from the prior art;

Figure 2 is a high level schematic illustration of an genetic programming arrangement in accordance with an embodiment of the present invention; Figures 3A to 3C are schematic illustrations of a Petri net in different states; Figure 4 is a schematic illustration of a protocol stack; Figures 5 to 7 are schematic illustrations of arrangements which may be used to evolve one or more computer programs arranged to implement a communications protocol; Figure 8 is a flow chart showing processing carried out in embodiments of the present invention to evolve a network protocol; Figure 9 is a flow chart showing processing carried out by a sending device according to the Alternating Bit Protocol; Figure 10 is a flow chart showing processing carried out by a receiving device according to the Alternating Bit Protocol; Figure 11 is a diagram showing a sequence of exchanges between a sender and receiver according to the Alternating Bit Protocol; and Figure 12 is a schematic illustration of a computing device arranged to implement an embodiment of the present invention.

Figure 1 schematically illustrates, at a high level, a known approach to genetic programming. An evolution engine 1 supplies candidate programs to a functional testing engine 2. The functional testing engine 2 supplies predetermined inputs to each candidate program for each of which there is one or more expected outputs. The actual output of a candidate program in response to a supplied input is compared with the expected output to give that candidate program a fitness rating. As the functional testing needs to provide an evolution of the candidate programs, partially correct candidate programs are given a non-zero score. A predetermined number of the fittest candidate programs (those having the highest scores) are then fed back to the evolution engine 1 which uses these fittest candidate programs to generate a new set of candidate programs. The newly generated candidate programs are then supplied to the functional testing engine 2 to undergo functional testing. In this way, better candidate programs are iteratively evolved based on the fittest candidate programs from a previous generation of candidate programs, the fitness of a particular candidate program being determined by functional tests.

Figure 2 schematically illustrates, at a high level, an approach to genetic programming according to an embodiment of the present invention. It can be seen that the evolution engine I provides candidate programs to a formal verification engine 3. Formal verification engine 3 performs formal verification tests, such as model checking, on each candidate program to give each candidate a fitness score. The candidate programs deemed to be fittest by the formal verification engine 3 on the basis of the generated fitness scores are then passed to the functional testing engine 2 to undergo functional testing as described above with reference to Figure 1. The fittest candidate programs, as determined by the functional test engine 2, are then passed back to the formal verification engine 3 for further formal verification to remove further weaker candidate programs. When a predetermined criterion is met, for example a predetermined number of candidate solutions are remaining, the fittest candidate programs are passed back to the evolution engine 1 so that a new generation of candidate programs can be evolved based on the fittest candidate programs as determined by using both the formal verification engine 3 and the functional test engine 2.

It will be appreciated that while Figure 2 illustrates an embodiment in which formal verification is performed both before and after the functional testing, alternative embodiments of the present invention may conduct formal verification solely before or solely after functional testing. Furthermore, whilst functional testing is necessary before a final candidate solution is selected, in some embodiments of the present invention, functional testing need not be performed for each iteration of testing and evolution.

Some of the examples described herein relate to the modelling of protocols. Petri nets are directed bipartite graphs suitable for modelling protocols. Petri-nets describe a system in such a way that its inherent parallelism, asynchrony, and indeterminism are apparent. Simple Petri nets comprise two types of node, places and transitions. Nodes are linked by directed arcs. An arc may connect a place to a transition or a transition to a place, but arcs may not connect a place to a place or a transition to a transition.

Each transition has a number input places to which it is connected via a number of input arcs, and a number of output places to which it is connected via a number of output arcs. Arcs can be weighted, a shorthand notation for multiple parallel arcs.

A place may be both an input place and an output place for a particular transition.

States of the system are modelled by placing tokens at places. Petri nets are often represented graphically. Generally, places are indicated by circles, transitions by rectangles or lines and tokens as black dots or pairs of square brackets placed within the places.

Algebraically, the basic Petri-net can be described as a 4-tuple, comprising P, the (finite) set of places, T the (finite) set of transitions (these two sets being distinct), the incidence function A and an initial marking M0. These elements can be conveniently represented in matrix form, with P, T and M0 being vectors.

Different states of a simple Petri net are graphically illustrated in Figures 3A to 3G.

Referring to Figure 3A, a Petri net is shown having two places 10, 11 and a single transition 12. The place 10 is an input place of the transition 12, connected to the transition 12 by an arc 13. The place 11 is an output place of the transition 12, connected to the transition 12 by an arc 14.

Petri nets may be thought of as condition/event graphs, where places represent conditions and transitions represent events. A transition may only fire if all of the conditions for that transition are met. A transition's conditions are met when there is at least one token for each of that transition's input arcs. When a transition fires, one token is moved along each of that transition's input arcs and a token is deposited at each of that transition's output places.

Referring again to Figure 3A, the transition 12 may fire, as there is a token 15 at the place 10. Referring to Figure 3B, the transition 12 is shaded to illustrate a firing of that transition. When the transition 12 fires, the token 15 is removed from the place 10 and moved to the place 11, as shown in Figure 3C. When the Petri net is in the state shown in Figure 3C the transition 12 can no longer fire as there are no tokens at its only input place, the place 10.

Generally, tokens may be present at any place in a Petri net, and any enabled transition may fire. The selection of which of a plurality of enabled transitions fires is indeterminate, making Petri nets well suited to modelling protocols.

In the arrangements of both Figures 1 and 2 the evolution engine I initially generates a set of candidate programs by combining predetermined program terms in accordance with predefined rules. Such rules may include a grammar for the programming language or Petri-net representation being used. In order to derive further generations of candidate programs the evolution engine 1 uses a variety of processes. These processes typically include reproduction (where a program is wholly copied exactly), mutation (where a program is wholly copied with random variations, for example, a random replacement of a sub-tree with a function, the random replacement of terminals, the random definition of terminals with values, or variation of terminal values), and recombination (where a sub-tree from one program is replaced with a sub-tree randomly selected from another program).

The genetic programming methods described herein which combine formal verification with functional testing are widely applicable to a variety of applications where both functional tests and formal verification requirements can be defined. One particular application where the methods described herein find applicability is the creation of modules to implement network protocols.

In a wireless communication network, various hardware components of a communications device, when configured by suitable software, facilitate the establishment of wireless communication with another communications device. This is achieved by means of a plurality of functional elements that are each operable to process data in preparation for transmission over an established communications channel, and to process data received from a communicating device.

To ensure that communications devices process data for transmission so that the data can be correspondingly processed at a receiving device, communications protocols have been established and communicating devices are arranged to comply with a common protocol to facilitate communication. Conventionally, the functionality required for the processing of data is represented as a number of layers in a protocol stack, where each layer is applied to the data in turn before transmission or after reception of that data. These layers can be developed separately provided that they conform to agreed methods by which to cooperate with each other. Thus a module developed to deliver the functionality of one layer is required only to conform to a specification of the data to be transferred to adjacent layers in the stack.

Figure 4 schematically illustrates a protocol stack in accordance with a generally accepted multi-layer specification, namely the OSI model. Different layers of the protocol stack provide different functionality required to allow communication between two devices. Layers progress from providing support to host applications (layers 7 and 6) to physical transmission/reception of a signal (layer 1). The OSI model will be well known to those skilled in the art and comprises an application layer (layer 7) a presentation layer (layer 6), a session layer (layer 5), a transport layer (layer 4), a network layer (layer 3), a data link layer (layer 2) and a physical layer (layer 1). It will be appreciated that other multi-layer architectures and models, such as the TCP/IP model, are also commonly used.

The data link layer (layer 2) comprises several sublayers including a Logic Link Control (LLC) sub-layer and a Medium Access Control (MAC) sub-layer. Both are conventionally operable in accordance with an established communications standard to ensure that data is presented to another communications device in a readable format.

For example, the functionality of the LLC sub-layer may be defined to operate in accordance with IEEE standard 802.2, and the functionality of the MAC sub-layer may be defined in accordance with IEEE 802.11.

The techniques described herein can be used to evolve a computer program arranged to implement any part of the protocol stack. In some embodiments, such a computer program is arranged to implement the MAC sub-layer of the data link layer.

Figures 5 to 7 illustrate arrangements which can be used to evolve computer programs arranged to implement a network protocol to be used for communication between two computing devices 5, 6. The protocol can be a complete protocol stack, or any part of a protocol stack such as that described above with reference to Figure 3.

Figure 5 illustrates a divide-and-conquer strategy for evolution of computer programs arranged to implement a communications protocol whereby a first computing device 5 evolves a computer program arranged to transmit data, while a second computing device 6 evolves a computer program arranged to receive data. In such an arrangement, where the computing device 5 is only required to transmit data, and the computing device 6 is only required to receive data, it can be seen that the independent evolution of computer programs providing transmitter and receiver functionality (in accordance with predetermined parameters) provides both the computing device 5 and the computing device 6 with the required functionality.

However, where both of the computing devices 5, 6 are to transmit data, it is necessary to transmit the evolved program providing transmitter functionality from the computing device 5 to the computing device 6. Similarly, where both of the computing devices 5, 6 are to receive data, it is necessary to transmit the evolved program providing receiver functionality from the computing device 6 to the computing device 5.

The arrangement of Figure 5 beneficially allows the task of evolving transmitter and receiver functionality to be divided between the computing devices 5, 6, thereby improving the speed with which the requisite computer programs are created.

Figure 6 illustrates an evolution strategy whereby each device 5, 6 evolves one or more computer programs implementing both receiver and transmitter functionality. Each computing device 5, 6 evolves its computer programs independently of operation of the other computing device based on a set of shared functional tests. Provided that the computer programs created by each of the computing devices 5, 6 meet the requirements of the shared functional tests, the computer programs will be able to provide functionality allowing data to be transferred between the computing devices 5, 6. This solution is particularly appropriate where the devices 5, 6 are communicating over a low-bandwidth communication link that cannot support the transfer of computer programs providing functionality required by the communications protocol.

Figure 7 illustrates an evolution strategy whereby the computing device 5 evolves one or more computer programs providing all functionality of the relevant communication protocol independently of the computing device 6. The evolved computer programs are transmitted to the computing device 6 over an initial unoptimized communications link.

This solution is particularly appropriate where the computing device 5 has more processing power than the computing device 6, and even more so where the processing power of the computing device 6 is prohibitively limited.

Figure 8 is a flow chart illustrating the process of evolving computer programs arranged to implement a network protocol to be used for communication between the computing devices, 5, 6. The process illustrated in Figure 8 can be used, for example, to evolve a MAC protocol of the type described above.

Referring to Figure 8, at step Si, the computing devices 5, 6 determine a communications requirement and establish an initial unoptimized communications link using known techniques. For example, the initial unoptimized communications link may be established using initial, unoptimized computer programs provided to both computing devices 5, 6 which programs implement a predetermined communications protocol.

At step S2, protocol requirements and rendezvous points, defining aspects of the protocol that each computing device 5, 6 must adhere to, are established. The protocol requirements and rendezvous points will of course depend on the protocol to be evolved. The evolution of a MAC protocol as described above will require protocol requirements relating to the transmission of data packets to be defined. By defining protocol requirements appropriately, it is ensured that the evolved computer programs will properly enable communication between the computing devices 5, 6.

When the protocol requirements have been established at step S2, functional tests are determined at step S3 based upon those protocol requirements. That is, functional tests are determined to ascertain whether, and to what degree, a candidate program meets the established protocol requirements. Such functional tests can be defined by associating a particular input to a program to be assessed with one or more outputs which the program should provide in response to that input. A fitness function is arranged to indicate the degree to which a defined functional test is satisfied.

Processing passes from step S3 to step S4, where a population of candidate programs is randomly generated from an initial set of predetermined terms which are combined in accordance with a predetermined grammar. Where a protocol is to modelled by a Petri net, the grammar used defines a set of places and transitions between them. The transitions represent the various actions that the protocol is required to perform, for example sending an acknowledgement or forwarding a correctly verified packet.

From step S4, processing passes to step S5 at which each candidate program is evaluated using formal verification methods to give each candidate program a fitness score. The formal verification is arranged to identify those candidate programs which are likely to experience problems during execution. Such problems can include deadlock. Formal verification also helps identify relatively cluttered designs and programs having greater resource consumption. From step S5, processing passes to step S6 at which the fittest candidate programs are selected based upon the formal verification performed at step S5. Selecting the fittest candidate programs may, for example, involve selecting a predetermined number of the highest scoring candidates, or may involve selecting those candidate programs having a score above a predetermined threshold. Processing then passes from step S6 to step S7.

At step S7 it is determined whether functional tests should be carried out on the fittest candidate programs selected at step S6. Functional tests may be more expensive than formal verification, both in terms of computationai resources and in terms of their execution time. It may therefore be decided (if, for example, at step S5, each candidate program in the current generation received a fitness score based upon formal verification below a predetermined threshold) that resources would be better utilized by evolving a new generation of candidate programs based upon the fittest candidate programs selected at step S6. Therefore, if at step S7 it is decided that functional testing is not to take place on the current generation of candidate programs, processing passes back to step S4 and a new generation of candidate programs is evolved based upon the fittest candidate programs selected at step S6, formal verification of the selected candidate programs is carried out at step S5, before the fittest candidate programs from the evolved candidate programs are selected at step S6.

If, on the other hand, at step S7 it is decided to perform functional tests on the candidate programs selected at step S6, processing passes to step S8. At step SB, each candidate program in the current generation is evaluated using the functional tests defined at step S3 to give each candidate program a fitness score based upon the functional tests. From step S8 processing passes to step S9 at which the fittest candidates are selected based upon the fitness score generated on the basis of the functional tests. Selection of the fittest candidates at step S9 may be based upon the results of the functional tests in isolation, or may be based upon a composite score incorporating (perhaps with differing weights) the results of both the functional tests performed at step S8 together with the formal verification performed at step S5.

Processing passes from step S9 to step Sb.

At step SlO it is determined whether the evolution is complete. The evolution may be determined to be complete if, for example, a predetermined number of generations of candidate programs have been evolved, a predetermined time has elapsed or the generated fitness function values meet some predetermined threshold.

If it is determined that the evolution is not complete, processing passes from step Sb back to step S4 at which a new generation of candidate programs is evolved based upon the fittest candidates selected at step S9.

If, on the other hand, it is determined at step Sb that the evolution is complete then processing passes from step Si 0 to step Si I. At step Si 1, it is determined whether additional formal verification will be performed to further narrow the choice of candidate programs. The decision as to whether additional formal verification is to be carried out may depend upon the number of candidate programs selected at step S9 in the final evolution iteration, such that where a large number of candidate programs are selected at step S9, additional formal verification is carried out to further inform the selection of program to be used.

If at step Si 1 it is decided to perform additional formal verification, processing passes to step S12 at which the remaining fittest candidate programs from the final generation are subject further formal verification which can be used to narrow the set of candidate programs. From step Si2, processing passes to step S13 where the fittest candidate program is selected for implementation based upon the results of the formal verification and functional tests which make up the processing described above.

If, at step Sli, it is decided not to perform additional functional testing, processing passes directly from step Sib to step SI 3.

An example showing how formal verification and functional tests can be used in the evolution of a computer program is now described. The example is described in the context of evolving an implementation of the Alternating Bit Protocol (ABP) using a representation based upon Petri-nets.

Petri nets can be formally analysed. Table 1 shows various properties of Petri nets which can be analysed. Such analysis provides a value for each of the listed properties. These values can be combined to provide an overall score for a Petri net, taking into account a relative importance weighting given to each of the properties.

Suitable weightings are also shown in Table 1 below.

Mnemonic Property Description Weighting

NB Net bound (upper bound value for entire net) 0.2 P1 Net-wide place invariant, tempered with a confidence 0.2 _____________ value _____________ AB Average upper bound per place if but only if there is 0.05 ____________ a net-wide place invariant. _____________ SDB Standard deviation of upper bound per place values, 0.05 _____________ If but only if there is a net-wide place invariant _____________ T 1 / the absolute number of transitions 0.05 P 1 / the absolute number of places 0.05 A 1 I the absolute number of arcs 0.05 DOA 1 / the number of dead transitions 0.15 DF Deadlock free (there is a transition invariant) 0.2

Table I

The properties shown in table 1 are as follows.

A Petri net is defined as bounded if an upper limit exists on the number of tokens that may accrue at any place. An unbounded Petri net is such that there is no limit on the number of tokens that can accrue in at least one place in the Petri net. In addition to being bounded and unbounded, a Petri net may be considered safe, meaning that there is at most a single token at any place in the Petri net at a particular time.

When modelling protocols, places may map to resources or memory locations and tokens may map to resources consumed. It is generally desirable to minimize resource usage. Knowing the upper bound of a plurality of Petri nets, each modelling an implementation of a protocol, provides valuable comparisons between the implementations modelled by the Petri nets in terms of their resource requirements. It will be appreciated that implementations which are represented by a bounded Petri net are preferred, given that resource usage can be known in advance, Implementations represented by a safe Petri net are even more preferred given that resources for only a single token are required at any one place in the Petri net.

An unbounded Petri net is given an NB value of 0', a safe Petri net is given a NB value of 1' and any other Petri net is given an NB value of 1/bound, where bound is the maximum number of tokens which can accrue at any one place.

The maximum number of tokens which can accrue at a single place in the Petri net can be determined by solving the equation: Ay=0 (1) Where A is the incidence matrix of the Petri net and y is a vector solution to the equation. The matrix A defines the weights of the arcs between transitions and places, and each element of the matrix A defines the weight of the arc from transition i to place j. The equation can be solved using well known techniques such as Gaussian elimination.

Having solved equation (1), the bound value may be determined either by exhaustively searching the state-space and keeping count of the maximum number of tokens which accrue at any one place, or by finding the minimal support invariants as will be apparent to those skilled in the art. From the minimal support invariants of the place invariant, an upper bound on the number of tokens in any place can be calculated according to the equation: M(p) �=Min[(M0] (2) L (Y1C")) where M(p) is the upper bound on the marking of place p, and yi(p) is the element in the place invariants vector corresponding to place p. The upper bound per place is therefore known and the bound value is simply the highest of the upper bound per place values. It will be appreciated that other methods of obtaining invariants, including siphon-trap analysis, incremental generation and axiomatic and partial-order techniques may also be used.

A place invariant defines a statement regarding some or all of the places in a Petri net.

Typically, this would be that the number of tokens in a group of places never exceeds a certain value, for example, equal to that at the initial marking. The P1 value of Table 1 is a Boolean value indicating whether the Petri net has a place invariant. Whether a Petri net has a place invariant can be decided based upon whether a solution y to equation (1) can be found.

The P1 value is preferably further based upon a check as to whether solutions of equation (1) conform to an analysis of the free variables in equation (1). If the number of free variables in equation (1) is not equal to the number of solutions to equation (1) it may be assumed that an error has occurred. Where this is the case the P1 value is set to be 0.5 to indicate that the values are not as expected.

If there is a net-wide place invariant, it is possible to calculate an upper bound for each individual place in the net and therefore an average upper bound, and the standard deviation of upper bounds. This provides differentiation between Petri nets between which the Net Bound value could not discriminate. For example, the net bound value would not discriminate between a Petri net where only one pIace in the net has a high bound but each other place was safe and a net where every place has a high bound.

Using the average and the standard deviation of upper bounds per place, two such Petri nets can be differentiated.

Therefore, where there is a net-wide place invariant, the value AB indicates the average of the bounds of each place, while SOB indicates the standard deviation of the bounds of each place.

Generally, the lower the AB value the better, (since a lower AB value implies that the algorithm requires fewer resources) however an AB value of zero is not ideal because a place that does not accrue any tokens is not having any great effect on operation of the Petri-net. The computed average value is therefore inverted to provide the AB value unless the average is zero in which case the AB value is 0. The AB value cannot exceed 1 to ensure that the AB value does not undesirably dominate computation of the overall score. The computed value is halved if the check described with reference to the P1 value is not satisfied.

If the computed standard deviation is 0, this indicates a good Petri net on the basis that there is no deviation or variance between places in the Petri net, and the SDB value is therefore set to be 1. Any other value for the standard deviation results in the reciprocal of the value being taken to provide the SDB value. The SDB value is halved if the check described with reference to the P1 value is not satisfied.

The 1, P and A values shown in Figure 1 each represent a respective simple structural property of the Petri net. The value T is computed by taking 1 / (the absolute number of Transitions), the value P is computed by taking 1 I (the absolute number of Places), while the value A is computed by taking. 1 I (the absolute number of Arcs). It is assumed for the purposes of analysis that smaller, less complex solutions are preferred. Petri nets having fewer transitions, places and arcs therefore receive higher values for these metrics.

The DOA value is computed by taking 1 I (the number of dead transitions). A dead transition is a leaf-node transition. It is assumed that leaf-node transitions are not useful for the type of Petri nets being considered. Petri nets having a large number of leaf node transitions therefore generate relatively low values for the DOA.

The DF value is a Boolean value indicating whether the net is capable of deadlock.

The DF value is determined on the basis of the existence, or otherwise, of a transition-invariant. A transition-invariant is a neutral sequence of firings that return a Petri net to a previous marking (usually the initial marking). If such a cyclic sequence exists then a Petri net can never deadlock.

Each of the above values is weighted according to its perceived importance in the analysis, the weightings being shown in Table 1, and the weighted values are combined to provide an overall score which is the output of the formal analysis.

By modelling evolved implementations of a protocol using Petri nets, measurements such as the above can be used to formally analyse those implementations. It will be appreciated that any other appropriate analysis tool, measurements or weightings may equally be used.

The alternating bit protocol (ABP) is a protocol commonly used in the area of formal methods to illustrate the modelling of protocols. The ABP captures the behaviour and properties of any acknowledged protocol that uses a data/ack handshake. The ABP is a sliding window protocol having a window size of one such that the sender transmits one frame in a sequence and waits for an acknowledgement to that frame before sending the next frame in the sequence. Each frame is identified with a sequence number, of either 1 or 0. The receiver must acknowledge each received frame with an acknowledgment having the same sequence number before the sender will send a frame having the next sequence number.

Figure 9 illustrates the processing carried out by a sending device implementing the ABP. At step S15 a first frame, having a sequence number of either 1 or 0, is sent to a receiving device. At step S16 the sending device determines if an acknowledgement, corresponding to the last sent frame, has been received from the receiving device. If it is determined that a corresponding acknowledgement has been received, processing passes to step S17 and the frame sequence number is updated. If the first frame had a sequence number of 1, the updated sequence number will be 0 and vice versa. The frame sequence number may, for example, be implemented as a single bit and may be updated using modulo-2 addition. From step S17, processing passes to step S18 where the next frame, having the updated sequence number, is transmitted to the receiving device. From step S18 processing passes back to step S16.

If, at step S16, it is determined that a corresponding acknowledgement has not been received from the receiving device, processing passes to step S19. At step S19 it is determined whether a time-out condition has occurred. A time-out condition may occur if, for example, the sending device does not receive a corresponding acknowledgement from the receiving device within a predetermined time. If it is determined that a time-out condition has not occurred, processing passes back to step S16.

If, on the other hand, it is determined at step S19 that a time-out condition has occurred, processing passes to step S20 and the last frame is retransmitted. From step S20 processing passes back to step S16.

Figure 10 illustrates the processing carried out by a receiving device implementing the ABP. At step S25 a first frame, having a sequence number of either 1 or 0, is received from a sending device. Processing then passes to step S26 where the receiving device sends an acknowledgement having a sequence number corresponding to the first received frame. At step S27 it is determined whether the next frame (i.e. a frame having the next sequence number) has been received from the sending device. If it is determined that the next frame has been received from the sending device, processing passes to step S28 and the acknowledgement sequence number is updated and at step S29 the next acknowledgement is sent to the sending device. Processing passes from step S29 back to step S27.

If at step S27 it is determined that the next frame has not been received from the sending device, processing passes to step S30. At step S30 it is determined whether a time-out condition has occurred. If it is determined that a time-out condition has occurred, processing passes to step S31 and the last acknowledgement is retransmitted. Processing then passes from step S31 back to step S27. If, on the other hand, it is determined at step S30 that a time-out condition has not occurred, processing passes from step S30 back to step S27.

Figure 11 illustrates the interaction beiween a sending device and a receiving device using the ABP according to the processing described above with reference to Figures 9 and 10.

Referring to Figure 11, at a time ti a sending device sends a frame SEQ 1 to a receiving device. The receiving device receives the frame SEQ 1 at a time t2. At a time t3 the receiving device transmits an acknowledgment ACK 1 to the sending device to acknowledge receipt of the frame SEQ 1. Also at the time t3, a timeout condition occurs at the sending device, and the sending device retransmits the frame SEQ 1 to the receiving device. At a time t4 the sending device receives the acknowledgement ACK 1. Also at the time t4, the receiving device receives the retransmitted frame SEQ 1. As this is not the next frame (step S27 in Figure 10) receipt of this frame at the receiving device does not cause a corresponding acknowledgment to be transmitted.

At a time t5 the sending device transmits a next frame, SEQ 0 and this is received at the receiving device at a time t6. At a time t7, the receiving device transmits an acknowledgment ACK 0 to the sending device to acknowledge receipt of the frame SEQ 0. The acknowledgment SEQ 0 is received at the sending device at a time t8. At a time t9, the sending device transmits a next frame, SEQ 1. At a time tlO, a time-out occurs at the receiving device and the receiving device retransmits the acknowledgment ACK 0. At a time tI 1, the retransmitted acknowledgment ACK 0 is received at the sending device. As the sending device is waiting for an acknowledgment to the frame SEQ 1, receipt of the retransmitted ACK 0 does not cause a next frame to be transmitted. At a time t12, the receiving device receives the frame SEQ 1.

Table 2 shows an example output of an analysis of a selection of Petri nets modelling various ABP designs, each design incorporating different assumptions (for example about the medium on which it is to be used) and! or containing deliberate errors (for example, having the potential for deadlock). The column headers of Table 2 correspond to the mnemonics of the formal analysis properties used to analyse each Petri net as shown in Table 1.

Protocol Total NB F AB SDB T P A DOA DF design Score ___ ABPfor perfect 0.778 0.2 0.1 0.05 0.05 0.013 0.005 0.005 0.15 0.2 medium _______ _____ ______ _____ _____ ______ _____ _____ ABP with lazy transmitter on 0.335 0 0.1 0 0.03 0.005 0.008 0.003 0.012 0,2 a noisy medium ________ _____ ______ ______ ______ ______ ______ ______ ABP for perfect medium but on 0.028 0 0 0 0 0.005 0.008 0.003 0.012 0 a noisy medium ________ _____ ______ ______ ______ ______ ______ ______ Payload ABP fornoisy 0.156 0 0 0 0 0.002 0.004 0.001 0.150 0 medium ________ ______ ______ Payload ABP transmitter 0.367 0 0.1 0 0.03 0.007 0.013 0.003 0.019 0.2 module ________ ______ ______ ______ ______ ______ ______ ______ Payload ABP receiver 0.373 0 0.1 0 0.03 0.006 0.013 0.004 0.025 0.2 module ________ ______ ______ ______ ______ ______ ______ ______ Payload ABP with deliberate 0.014 0.004 0 0 0 0.002 0.002 0.001 0.005 0 deadlock condition ________ ______ ______ ______ ______ ______ ______ ______

Table 2

In addition to formal tests, it is possible to use Petri net models of protocols to help to define functional tests.

The firing of transitions within a Petri net can be seen to correspond to external events, such as the transmission of a data packet. As such, it is reasonable to consider the firing of each event as the functional output of a protocol. By monitoring the sequence of transitions it is possible to define functional tests as follows: 1. For a particular protocol (e.g. the ABP), define a set of transitions that must be present; and 2. Define a set of rules that describe which sequences of transitions are correct, where each rule consists of the following parts; a. A filter expression that removes transitions that are of no interest to the rule; b. A pattern p that defines a short desirable sequence; c. An expression exp that defines how frequently that sequence should occur; and d. A weighting w that defines how important that rule is to the total functional score.

A particular implementation of a protocol may then be scored for a particular rule using the formula (2): (total number of times p occurs / exp) * w (2) A total functional score may then be built up from the summation of the scores for each particular rule.

It will be appreciated that formula (2) is suitable for use with protocols in which the number of times p occurs does exceed that defined by the expression exp. Where the total number of occurrences of p may exceed exp, a weighting mechanism may be employed to penalise Petri nets having patterns p which occur more frequently than defined by the expression exp.

It will be appreciated that while the above example has described a method involving the use of Petri nets for functional testing and formal analysis, alternative embodiments may employ other means of functional testing and formal analysis.

It will be apparent to a person skilled in the art that although fitter individuals are preferable, any individual from a population of evolved processes that is able to perform the task may feasibly be selected for use.

It will also be clear to a person skilled in the art that various methods of generating initial individual programs may be contemplated within the scope of the present invention.

It will also be clear to a person skilled in the art that other characteristics may be taken into account by the fitness functions described herein, including quality of service measurements for each device, or overall utilisation of a communication medium.

It will also be clear to a person skilled in the art that introns, (non-functional elements of an evolved program), may be deleted before final use of the selected program. For example, functions that are never called due to the program structure may be deleted, as may code implementing unrealisable conditions, such as if(1>2) then {...}.

Referring now to Figure 12, a mobile communication device in the form of a laptop 200 is illustrated in accordance with the specific embodiment of the present invention. The laptop 200 comprises a processor 230 operable to execute instructions stored in a working memory 240 and/or retrievable from a mass storage device 250. By means of a general-purpose bus 201, user interfaces 210 are in communication with the processor 230. The user interfaces 210 comprise, in this example, a keyboard and a pointing device, a visual display unit and a loudspeaker.

A communications unit 220 is connected to the general-purpose bus 201, and further connected to an antenna 225. By means of the communications unit 220 and the antenna 225, the laptop 200 is capable of establishing wireless communication with another cooperating device.

In the device of Figure 12, the working memory 240 stores user applications 245, a least one of which, when executed by the processor 230, configures a user interface to enable communication of data to and from a user. The applications 245 thus establish general purpose or specific computer implemented utilities and facilities that might habitually be used by a user.

In an embodiment of the present invention, the communications unit 220 comprises a means arranged in operation to carry out the functions of an OSI protocol stack.

Specifically, it comprises a medium access control unit operable to carry out the functions of the MAC sub-layer. The MAC protocol may be evolved according to the methods described above.

It will be clear to a person skilled in the art that any device may be used to implement embodiments of the present invention, for example mobile phones, PDAs, electronic games and media or multimedia entertainment devices.

The present invention may be implemented in any suitable manner to provide suitable apparatus or operation. An embodiment may consist of a single discrete entity added to a conventional host device such as a laptop, multiple entities added to a conventional host device, or may be formed by adapting existing parts of a conventional host device. Alternatively, a combination of additional and adapted entities may be envisaged. For example, processing means may reside within the laptop device 200 or within a distinct communication unit 220 housed on a PCMIA card.

Alternatively, processing may be shared between processing means of both. Thus adapting existing parts of a conventional host device may comprise for example reprogramming of one or more processors therein. As such the required adaptation may be implemented in the form of a computer program product comprising processor-implementable instructions stored on a storage medium, such as a floppy disk, hard disk, flash memory, RAM or any combination of these or other storage media or signals.

Various modifications and applications of the present invention will be readily apparent to the appropriately skilled person from the teaching herein, without departing form the scope of the appended claims.

Claims (21)

1. Claims 1. A method for producing a computer program comprising: storing a plurality of first computer programs in a memory; selecting at least some of said first computer programs, said selecting being based upon testing of each of said first computer programs for predetermined functionality, and analysis of at least one formal property of each of the first computer programs; generating a plurality of second computer programs based upon said selected first computer programs; and selecting at least one of said second computer programs.
2. 2. A method according to claim 1, wherein said plurality of second computer programs are generated using genetic programming techniques.
3. 3. A method according to claim 2, wherein said genetic programming techniques comprise at least one of mutation, reproduction and recombination.
4. 4. A method according to any preceding claim, wherein said plurality of first computer programs is randomly generated.
5. 5. A method according to any preceding claim, wherein selecting at least one of said second programs comprises testing each second computer program for predetermined functionality, and analysing at least one formal property of each second computer program.
6. 6. A method according to any preceding claim, wherein said at least one formal property is a plurality of formal properties.
7. 7. A method according to claim 6, further comprising: generating a value associated with each of said plurality of formal properties; and combining said values to generate said score.
8. 8. A method according to claim 7, wherein combining said values comprises combining said values in accordance with predetermined weights.
9. 9. A method according to any preceding claim, wherein said at least one formal property is selected from the group consisting of properties indicative of resource consumption, ability to deadlock, number of operations, number of program flows, and number of program variables.
10. 10. A method according to any preceding claim, wherein said first computer programs are each represented by a Petri net.
11. 11. A method according to claim 10, wherein generating a plurality of second computer programs based upon said selected computer programs comprises generating Petri nets representing each of said plurality of second computer programs.
12. 12. A method according to any preceding claim, wherein selecting at least some of said first computer programs comprises: generating a first score for each first computer program based upon analysis of at least one formal property of each first computer program; generating a second score for a subset of said first computer programs, said second score being based upon testing of each computer program of said subset for predetermined functionality, and said subset being selected based upon said first scores; and wherein said selecting of said first computer programs is based upon said second scores.
13. 13. A method according to claim 12, wherein selecting at least some of said first computer programs further comprises: for each computer program selected based upon said second scores, generating a third score based upon analysis of at least one formal property of computer programs selected based upon said second scores.
14. 14. A method according to any preceding claim, wherein testing a respective computer program for predetermined functionality comprises: applying at least one predetermined input to said computer program; and processing at least one output generated by said computer program in response to said at least one predetermined input to determine whether said at least one output satisfies a predetermined criterion.
15. 15. A method according to claim 14, wherein processing at least one output generated by said computer program in response to said at least one predetermined input to determine whether said at least one output satisfies a predetermined criterion comprises determining whether a predetermined output sequence is generated by said computer prograni
16. 16. A method according to any preceding claim, further comprising generating said plurality of first computer programs by combining terms of a predetermined set of terms in accordance with a predetermined grammar.
17. 17. A method according to any preceding claim, wherein said computer program is arranged to implement a communications protocol.
18. 18. A method according to claim 17, wherein said computer program is arranged to implement at least one layer of a protocoL stack.
19. 19. A method according to claim 17 or 18, wherein said communications protocol is a medium access control protocol.
20. 20. A method according to any preceding claim, further comprising providing the generated computer program to at least one further computing device.
21. 21. A method of generating an implementation of a communications protocol, the method comprising: generating a computer program providing first functionality defined by said communications protocol at a first computing device using a method according to any preceding claim; and generating a computer program providing second functionality defined by said conimunications protocol at a second computing device using a method according to aily preceding claim.22 A method according to claim 21, wherein said computer program providing first functionality and said computer program providing second functionality are arranged to allow communication between said first and second computing devices.23. A method according to claim 21, further comprising: providing said computer program providing first functionality to said second computing device; providing said computer program providing second functionality to said first device.24. A method according to any one of claims 21 to 23, wherein said first functionality is transmission functionality and said second functionality is reception functionality.25. A computer program arranged to carry out the method of any one of claims 1 to 24.26. A computer readable medium carrying a computer program according to claim 25.27. A computer apparatus comprising: a memory storing processor readable instructions; and a processor arranged to read and execute instructions stored in said memory; wherein said processor readable instructions comprise instructions arranged to control the processor to carry out a method according to any one of claims 1 to 24.28. A computer apparatus for producing a computer program comprising: a memory storing a plurality of first computer programs; means for selecting at least some of said first computer programs, said selecting being based upon testing of each of said first computer programs for predetermined functionality, and analysis of at least one formal property of each of the first computer programs; means for generating a plurality of second computer programs based upon said selected computer programs; and means for selecting at least one of said second computer programs.