Background of the Invention

This invention relates to control-intensive, and more particularly to the development of finite state machine implementations of such systems through a methodology based upon formal verifications.

Digital circuits that have memory are commonly referred to as sequential circuits of finite state machines. Finite state machines can be divided into two categories. One is signal processing machines whose proper operations must be described in terms of a routine which calls itself recursively, and the other is non-recursive control-intensive machines. FIR filters, for example, belong to the first category. Communication protocol hardware belongs to the second category. Design of control-intensive finite state machines is a difficult task. Typically, the objective of such a design is to efficiently and quickly develop an implementation that is correct, robust with respect to changes in data structures and easy to support.

The value of a particular formal verification framework may be measured by the scope or generality of the requirements for which an implementation may be tested. For example, one can verify that at each state the protocol will not do anything untoward. This may be sufficient in some applications and not in others. In connection with communications protocols, for instance, such verification is not sufficient because the primary concern is that a message should be received at the destination, and such verifications cannot guarantee that.

In order to ensure proper behavior of an implementation, extensive behavioral testing must be conducted. Normally that would imply extensive simulation, but it is now generally accepted that simulation is inadequate (the set of possible sequences of input signals that must be simulated for complete confidence is infinite). Formal verification techniques, on the other hand,' can have the power to draw conclusions about the general behavior of a system under all situations through a finite test.

Since requirements address broad properties of a finite state machine, formal verification is most easily and most often applied to a high-level model or abstraction of the implementation. Such verification is not enough. For verification of a high-level model to have real meaning for an implementation, there must exist a formal association or transformation from the high-level model to the implementation.

Even in the absence of a formal transformation from an abstract model to its actual implementation, formal analysis of the model is useful. In connection with finite state machines that embody a protocol, for example, formal analysis discloses faults in the very concept of the protocol itself. However, it is deceptive to refer to an implementation as "verified" in the absence of such faults if there is no formal, testable, relationship between the verified model and its actual implementation.

A simple way to define a formal relationship between a high-level model or standard and an implementation is to associate a state in the model or standard with a set of states of the implementation. Such an association, for example, may require that the Receiver-Ready state of the high-level model of a communications protocol correspond to the set of implementation states for which a certain state machine component of the protocol implementation is in its Receiver-Ready state. The set of implementation states for which this state machine component is in the Receiver-Ready state may be very large since the state is determined by all the possible values of pointers, buffers, counters and so on in the circuit which may occur together with the state machine component having state Receiver-Ready. If one were to suppose that according to the high-level model or standard, the correct transition from Receiver-Ready is to the state Transmit, still it may be that for certain implementation states (i.e., for certain of pointers, buffers and so on) the implementation tracks the model or standard, while for others it does not. To certify truly that a high-level model or standard abstracts an implementation, it would be necessary to demonstrate this abstraction not only for a single implementation state and transition corresponding to each respective high-level state and transition, but rather for every low-level state and transition. Indeed, it is well-known that the greatest weaknesses of an implementation arise at the "boundaries" of operation (buffer empty, buffer full, etc.) and that these "boundaries" can be very complex.

As intimated above, one could use the brute force technique of simulating all possible states of the model (i.e., all possible combinations of pointers, buffers, etc.), but this is rarely practical. While a high-level model or standard may have as few as 50 to 500 states, an implementation typically has such a larger number of states that the number can be appreciated only by analogy. For example, given all the possible combined values of its pointers, buffers and state machine controllers of an "average" protocol implementation, it turns out that the state space of a circuit contains approximately 10 reachable states. Supposing that a brute force verification algorithm were perfectly parallelizable among every human being on earth, and each person, in order to accomplish his or her piece of the work, were given a super computer. With 10 states, the verification job could not be completed before the sun turned to stone.

Since it is rarely feasible to address directly all possible transitions of an implementation (i.e., to address all possible values of pointers, buffers, etc.), there must be an alternative by which to conclude that an implementation is faithful to its high-level abstraction.

Lastly, having formal verification together with a comprehensive and a proven method for transforming high level description to low level specifications is still insufficient in light of the tremendous complexity that finite state machines may represent. To reduce this complexity, artisans have attempted to replace complex problems with simpler presentations. K. G. Larsen et al. in Lecture Notes in Computer Science, Springer-Verlag, 14th International Colloquium Karlsruhe, Federal Republic of Germany, July 13-17,1987 Proceedings, presented a compositional proof, by decomposing the system and demonstrating properties of the subsystems that are strong enough to hold true for the complete system. However, they have not provided a methodology for proving that their substitutions (of complex problems with simple problem equivalent) are valid.

In short, what is needed to the development of control-intensive FSM's is an automated software-aided design approach that incorporates formal verification, formal behavior-preserving transformation from a high-level to a refined implementation, and the means to manage the ensuing complexity brought on by the refined implementations.

Summary of the Invention

We present a high-level to low-level transformation in the form of a formal top-down development procedure based upon successive refinement. Starting with a high-level (abstract) model, such as a formal abstraction of a protocol standard, successively more detailed models are created through successive refinement. The refinements are created in a fashion which guarantees that properties verified at one level of abstraction hold in all successive levels of abstraction. The successive refinements end with a low-level "model" which forms the ultimate implementations of the protocol.

In one embodiment of this invention, the analysis/development apparatus creates a unique C language code representation of the specified system that is guaranteed to carry out the tasks specified when executed in a stored program controlled machine. The code is stored in the memory of a software-controlled processor which carries out the instructions of the code and thereby realizes the desired finite state machine. In another embodiment, the code is used to create a "net list" which is transformed to a set of layout masks and the masks are employed to manufacture integrated circuits of the specified system.

Brief Description of the Drawing

• FIG. 1 presents a general block diagram of the analysis/development apparatus of this invention;
• FIG. 2 expands in the block diagram of FIG.1.
• FIG. 3 illustrates the homomorphism concept embodied in the analysis/development approach of this invention;
• FIG. 4 presents an example of a protocol apparatus and the task-relative reductions that may be applied;
• FIG. 5 presents a general block diagram of our embodiment of a "crank machine";
• FIG. 6 depicts a flow chart for cycling through selections and states; and
• FIG. 7 illustrates the structure of the code used in the verification blocks and the signal set that is developed by block 30 of FIG. 2.

Detailed Description

As indicate above, this invention deals with the need to create a finite state machine that implements given functions, and to formally verify that the implemented machine carries out the intended functions without fail. This invention realizes the targetfinite state machine in a program controlled processor or in a specifically designed apparatus. The code which comprises the program that implements the target state machine in a processor, and which dictates the circuit's structure in a hardware embodiment, is developed by the analyser/developer described hereinafter.

It should be understood at the outset that this invention creates a unique end product, and that is the finite state machine which is developed in accordance with the principles of this invention. This machine has unique properties as described infra. This invention also creates another product, and that is the formally verified specification that is suitable for developing the finite state machine (FSM); whether the FSM is embodied in "conventional" hardware (e.g. integrated circuit) or in software-controlled hardware. In connection with software-controlled embodiments, it should also be recognized that technological efforts have shifted greatly toward the developement of control systems in software-controlled hardware, and many worker-hours have been devoted to the software generation effort. Such software generation efforts are greatly benefited by the method of this invention. So, this invention may be property viewed as a tool for creating software controlled hardware.

Developing a verified design of a finite state machine in accordance with the principles of this invention contemplates an interactive design process. With reference to FIG. 1, which depicts a generalized block diagram of the design analyzer/developer of this invention, the user enters into refinement block 10 a high level specification of the system to be designed. When block 10 determines that the specification contains no intemal inconsistencies, the system specification information is passed to verification block 20. Block 20 receives task specifications from the user and formally verifies that the specified tasks are properly executed by the structure defined by the system specification provided by block 10. When an error is detected in blocks 10 or 20, an error message is sent to the user on status lines 11 or/and 21 and the user is given an opportunity to correct the error through input lines 12 and 22. When no errors are detected, the design iteration is completed.

The next iteration is initiated when the user provides more detailed information about the system's specification and identifies a more comprehensive set of tasks that the system must perform. At that time, block 10 analyses the refinement in the system specification provided by the user to determine that the refined specification is subsumed by the specification verified in the previous iteration. When no errors are detected, the refined specification is passed to block 20, where it is assessed whether the newly specified tasks are properly executed by the structure defined by the refined specification.

Following a number of such iterations, the system specification contained in block 10 is sufficiently detailed and robust to execute all of the necessary tasks. That is, the specification is robust enough to cause all of the expected, or target, outputs to be developed in response to the possible applied inputs. Typically, at that time the design process proceeds to block 30. Block 30 converts the system specification within block 10 to a form that enables the user to construct the designed machine. In today's milieu, that may be a program to be executed on a stored program processor, it may be a collection of logic expressions that define the combinatorial circuit that forms the designed finite state machine. It may also be a net list for constructing a lay-out of an inter- grated circuit.

FIG. 2 presents a more detailed description of the FIG. 1 arrangement. Refinement block 10 contains refinement storage block 13, refinement verification block 14 and system definition storage block 15. Blocks 13 and 15 provide signals to block 14 and, in turn, block 14 provides corrections signals to block 15. Block 14 also provides signals to status line 11. In operation, the design process begins with an empty system-storagee block 15. The user provides a high level definition of the system to be designed to block 13 and the analysis proceeds. Generally, block 14 analyses the contents of block 13 to determine that the system definition of block 13 is subsumed by the system definition of block 15. In the first iteration, however, the affirmative conclusion of such analysis is automatic because block 15 is empty. This affirmative conclusion (i.e., the conclusion that the specification is error free) leads block 13 to transfer its contents to block 15 and to send a message on status line 11 that informs the user of the successfull conclusion of the current iteration.

When the next iteration is initiated, the user inputs a refined definition of the system into block 13 and a mapping. The mapping maps the states, and actions at the states, of the system specification in block 15 to the states and actions at the states of the system specification in block 13. That is, it maps states to states and actions to actions, as depicted in FIG. 3.

FIG. 3 shows a portion of the system definition in block 15 as Level 1, and the more refined system definition in block 13 as Level 2. Specifically, Level 1 shows that there is a state "READY" and a state "MSG", an action "SEND-MSG", and a selection of state "SMG" when that action occurs. FIG. 3 also indicates that there exists a mapping Φ form level 2 to Level 1. Level 2 shows that there is a state "READY" and states "MSG1', "MSG2",... "MSGM" which are selected following the actions "SEND_MSG1", "SEND_MSG2",..., "SEND_MSGM". The mapping Φ is such that

• Φ(state in Level 2) ⇒ state in Level 1, and
• faction in Level 2) => action in Level 1.

Block 14 analyzes that refined definition and the mapping vis-a-vis the definition contained in block 15. If an error is detected, status line 11 provides a diagnostic message to the user. The user can then correct the refinement contained in block 13 and try again. When no errors are detected, the contents of refinement storage block 13 are transferred through block 14 to system definition storage block 15. The iterative process continues until the system definition in block 15 is detailed enough.

In connection with the inputs to the FIG. 2 arrangement, it should be recognized that there are many ways of defining a system, and that the invention disclosed herein does not depend on that choice. The available choices include boolean expressions, directed graph descriptions, and others. In our implementation, we selected the signal graph approach, which is fairly conventional. In this approach, a system is defined as a collection of process states and transitions between the process states. At each process state, certain selections are possible as a function of the state. Associated with each state transition is an enabling predictate which is expressed in terms of the selections in this process state and other process states with which this process state communicates.

The syntax for describing the system as a collection of process states (nodes) and transitions (edges) forms a data flow language. Such a language includes means for identifying nodes and for identifying the edges. The S/R language, which is modeled after the s/r model of coordination, is the language we use. It is basically defined in Appendix A.

The primary formal verification performed in block 14 is the task of determining that every edge in the refined system definition of block 13 maps onto, or corresponds to, exactly one edge in the system definition of block 15. Basically, the task is to through each edge in the state space representation of the specification in block 14 and determine that, in accordance with the specified mappings, there is a corresponding edge in the state space representation of the specification in block 15. A more detained description is presented infra.

With each successful conclusion of an iteration within block 10, the specification within block 13 is transferred to block 15, and system definition information within block 15 is communicated to verification block 20. As indicated above, block 20 verifies that the system definition contained in block 15 can properly execute the necessary tasks of the system. The user inputs task definitions into block 23. Block 24 receives from the user reduction information to permit the analysis/development apparatus of FIG. 2 to evaluate whether the tasks are being properly performed. More specifically, the user supplies task definitions to block 23 and reduction mappings to block 24. Each reduction R is associated with a task T. With respect to task T the correctness of system operation can be ascertained by determining whether the task is performed by the reduced version as defined by reduction R_i.

The reductions of block 24 are verified vis-a-vis the system definition provided by block 15. This verifications is performed in reduction verification block 25. The verification is performed on one task at a time. That is, each reduction is tested to determine whether it is a valid reduction, which means that the reduction leaves the operation of the reduced system invariant vis-a-vis the task. Concurrently, the task is tested in block 26 with respect to its reduced system to determine that it can be performed properly. When an error is detected in either block 25 or block 26, status line 21 provides the user a diagnostic message which enables the user to correct the system definition, the tasks defined, or the reductions. When no errors are detected, the processing advances to the next task and corresponding reduction mapping, until all tasks pass the tests successfully. The actual testing that is performed in verifying each reduction mapping is the same as the testing performed in verifying the mappings associated with the system refinements (block 14). That is, mathematically, the relationship between the system reduction (relative to some task) and the unreduced system is much like the relationship between the system definition within block 15 an the refined system definition within block 13. As an aside, in some of the literature, these mappings are sometimes referred to as "homomorphisms".

Once the reductions have been verified in block 25, block 26 determines whether each of the specifies tasks is properly executed by its reduced system. The verification of block 25 insures that if a task is performed by its reduced system, it is also performed by the unreduced system. Checking the reduced system, of course takes substantially less time. There are many algorithms for checking that a task is performed by a system. One such algorithm is described in an article by R.P. Kurshan titled "Reducibility on Analysis of Coordination", plublished in Lecture Notes in Computer Science (LNICS) 103 titled Discrete Event Systems: Models and Applications, Springer-Verlag, pp. 19-39, (1987). As an aside, in some of the literature, these algorithms are sometimes referred to as "language containment" algorithms.

When all of the tasks have been analyzed successfully, status line 21 informs the user that the iteration is complete. Thereafter, the user advances to the next iteration. The user provides a refinement of the system (to block 10), defines a more comprehensive set of tasks to be performed by the refined systems and reductions for testing the new set of tasks.

As described above, the arrangement of FIG. 2 carries out the testing functions, and the successful end result is a specification within block 15 that is as detailed as necessary for carrying out all of the specified tasks; i.e. all of the target output signal can be developed for the various possible input signals. At this time code generator 30 is engaged to develop explicit code for implementing the finite state machine. This code can be targeted for installation into a stored program controlled processor that would embody the finite state machine, or it can be code that forms an input to a step of developing the necessary information for a special purpose hardware realization. Such information, for example, can be a "net list" that defines the connections between various elements of an integrated circuit embodiment. The net list can be used directly to build the target FSM, or it can be transformed to one or more masks that are used to manufacture integrated circuits that realize the target FSM.

Before providing additional details regarding the verifications performed in blocks 14, 25 and 26, a qeneralized example of the above-described principles may be beneficial.

FIG. 4 presents a block diagram of a controller whose design is to be formally developed and verified in accordance with the principles of this invention. It includes, a CPU 100 and a packet layer controller (PLC) 200. CPU 100 includes a bus manager 110, interface driver 120 and applications 130. PLC 200 includes a general manager 210, an administration block 220, a task manager 230, a restart block 240, a receiver 250, a sender 260, a timer 270, a tasks queue block 280, and a ROM manager 290. Associated with the PLC are incoming and outgoing queues 310-370 and a protocol ROM 380.

One of tasks that applications block 130 needs to have executed is an "enque-msg" task wherein the application outputs an "enque-msg" token and puts a message on an output message queue, e.g. queue 330. The "enque-msg" token is interpreted by driver 120 and sent to command queue 370. At the same time task manager 270 is informed of the insertion of the interpreted token into the command queue. The task manager picks the queued message off the command queue, brings it down to task queue 280, and from there send it into sender 260. The sender gets access to the protocol in ROM 380, through ROM manager 290 and general manager 210. General manager 210 controls conflicts in the ROM and in the system bus which does the processing of the "enque-msg" task in accordance with the protocol. It eventually succeeds in moving the data from the output message queue down to the link.

In order to verify this task, it is necessary to reduce the complexity of the FIG. 4 system because the system is too complicated. That is, as it stands, there are too many states that the system may assume to permit an efficient verification (from the standpoint of computation effort). Hence, the reduction step described above. The aim of the reduction is to abstract the portions of the system which aren't involved the interaction with the "enque-msg" task and to reduce those portions to a much simpler set of blocks which interact with the job of the sender and the other components but which is not otherwise proactive in connection with the task at hand. As long as their interaction or interfering is at least as great as the interaction of the real components, a proof that the "enque-msg" task is performed with the reduced system is also a guarantee that the task will be performed with the unreduced system. One possible reduction, for example, may encompass blocks 310, 320, 350, 360, 220, 270, 240, 250, and 290. One the other hand, it may turn out that even such a drastic reduction may not be encompassing enough.

One solution that can be employed is to decompose the "enque-msg" task into three subtasks. The first subtask may be to verify that when the application sends an "enque-msg", that the "enque-msg" token reaches the command queue. The second subtask may be to verify that, assuming the "enque-msg" token is somehow in the command queue, the task manager pulls it down properly to the sender. The third subtask may be to show that, assuming the "enque-msg" token is in the sender, the sender properly performs the data transfer to the link. To prove each of these substasks, a much larger portion of the system may be encompassed in the reduced blocks. The resulting simpler system can then be analysed and the subtasks proven more easily. Of course, there is an additional verification step that must be undertaken and that is to prove that performing the subtasks is tantamount of performing the original "enque-msg" task.

Returning to the verification performed in block 14, as indicated above, the relationship between the system specification in block 15 and the more refined system specification in block 13 is defined by a mapping (homomorphism). To verify that the refined, more complex, specification is consistent with the less complex specification, it is necessary to test that whenever there is a transition from a state v to a state w in the more complex system which is enabled by a selection x and under the above mappings, v maps to v', w maps to w' and x maps to x', then the transition form v' to w' is enabled by x' (v', w' and x' relating to the less complex system).

The s/r model is employed to make the above evaluations. In simple terms, the slr model may be explained by considering a global selection, a global state, and a multiplicity of component finite state machines that coordinate to form the overall finite state machine. At each iteration of this model, each of the component finite state machine selects an output from among the outputs that are possible from its current state, and thus contributes to the global selection. It then observes the global selection and moves to a next state to which the finite state machine may go. These iterations can continue ad infinitum.

We implement the s/r model for verification purposes in what we call the "crank machine". It includes a multiplicity of modules that correspond to the multiplicity of coordinating component finite state machines, and means for iterating through four steps. In addition to the two steps described above of making a selection and resolving to a state (which form steps 2 and 3 of the crank machine), the crank machine includes a first step of unpacking a global state from a register and applying it to the component state machines, and a fourth step of packing the new global state and storing it in the register. The register serves as a communications interface between the componentfinite state machines, which provides for the interaction that is necessary between the component finite state machines. Each of the component finite state machines is responsive to the global state, and each of the finite state machines contributes to the creation of the next global state.

Of course, having the mere capability to cycle through various states of the system specification is insufficient for the purpose of testing the system specification. Means must be provided to actually cycle through all of the possible states and selections. It should be kept in mind that a system can have several selections when it is in a given state and, conversely, for each selection there can be resolution to one of several states.

To test a system specification, we employ a boundary queue memory 61, a reached state table (RST) 62, and a crank machine controller 63, as shown in FIG. 5. The boundary queue is a stack that can be accessed from the top or the bottom, and it contains a list of global state pointers that point to state of the system within the RST. The crank machine controller (a software controlled processor) pops a state from the top of the boundary queue, unpacks the state and applies it to various modules that represent the component finite state machines. It then generates all of possible selections, and for each selection generates all of the possible next states. With respect to each generated next state, the crank machine determines whether that state is already in the RST. If it's not in the RST, the crank machine adds the state to the RST and inserts a pointer in the boundary queue that points to the location of the inserted state in the RST. The pointer is inserted at the top of the boundary queue stack or at the bottom of the boundary queue stack, depending on the value of an acceptance criterion. More particularly, the pointer is inserted at the top of the stack when it is determined that access to the state was across a "recur" edge. This concept is found in the aforementioned LNICS paper by R.P. Kurshan.

The above-described process follows basically the flow of FIG. 6. In block 51, the state is unpacked from the buffer queue. In block 52, a determination is made whether there are selections to be made in the system which have not been made previously. When the answer is affirmative, a selection is made in block 53 and control passes to block 55. Otherwise, control passed back to block 51 where another system state is popped from the stack and unpacked by the crank machine.

In block 54 a determination is made whether there are states to which the system can move (based on the selection made) which haven't been identified before. When the answer is affirmative, block 55 resolves to that state and block 56 packs the resolved state and pushes it onto the boundary queue stack. When no additional states can be resolved, control passes back to block 52 to make another selection.

Block 56 in FIG. 6 includes the logic for determining whether to push the packed state into the top of boundary queue stack 61 of into it bottom. Block 52 includes the logic for cycling through the various selections that are made by the component finite state machines.

The modules within the crank machine controller correspond to the component finite state machines. In accordance with our invention, these modules are created by compiling the S/R language specification. Our compiler creates a code that converts the specification to a collection of switch action statements with a structure as outlined in the C-like code of FIG. 7 is merely illustrative and it is not intended to be exact. Executing the code "ccode.c" presented in the appendix B provides all of the necessary details for developing the actual code that FIG. 7 represents. For the illustrative purposes herein, FIG. 7 includes the "set state vector" construct to mark the effort of blocks 52 and 54 in connection with the cycling through all possible selections and all possible states that exist in the case statements that follow. FIG. 7 also includes a companion error statement with each of the action statements. The error statement entries represent the testing that is performed to effect the desired verification. One such testing is the stability testing. To test stability, one must determine that the specification is consistent with a continuous time asynchronous system definition. The theoretical treatment of the stability issue is presented in an article to be published, which is included herein in appendix D and made a part of this specification. The code for executing the stability test is included in the appendix C. It should be kept in mind that FIG. 7 represents only one component finite state machine and that the states and selections discussed above relate to global selections and global states.

The above describes the process of cycling through the various states that are possible and the various selections that are available. To perform the verification of block 14, the above process is applied to both, the specification of block 13 and the specification of block 15. The process is applied to both system simultaneously and at each step a determination is made to ascertain that when the system of block 13 experiences a transition from a state v to a state w which is enabled by a selection x, and the system of block 15 experiences the transitions from v' to w' in accordance with selection x', that v', w ' and x' are related to v, w and x by the mapping of block 13.

As indicated above, the verification process associated with block 25 is identical in kind to the verification process of block 14 and, therefore, for the sake of brevity, no more is said about it.

As for the code generator (block 30), it develops basically the same collection of switch statements that are created in the verification process of block 14. The only difference is that the testing submodules that are incorporated in the switch statements to cycle through all the possible states, for example, are removed. Also removed, of course, are the "error statements" entries of the FIG. 7 illustration. The result is that the code generator develops a code that has no calls to functions or subroutines. All of the decisions are made on one "level" of the switch statement. The results is that when the signals set that corresponds to the code package developed by the code generator is installed in a target machine (processor- memory combination) the resulting finite state machine is extremely fast. The difference between the finite state machine that is created with the signal set of code generator 30 and finite state machines developed by other means is akin to the difference in speed between a multiplier that comprises a processor that calculates products in accordance with some algorithm and a multiplier that comprises a look-up table (with the finite state machine of this invention being more like the look-up table).

Still, without more, the code generated by block 30 would comprise a collection of finite state machines. A still better product results, in accordance with our invention, by merging various subsets of the individual finite state machines into respective single one's. Pratically, that means combining a number of switch statements into a single switch statement. Accomplishing such merging is not difficult; one needs only to realize of its effect, which is to decrease execution time at the possible expense of increased memory in software.

This effect of code lengthening in consequence of merging may be ameliorated by another step carried out in block 30, and that is a step of relative reduction on each of the various merged machines. The concept of reduction is not new. Conventional finite state machine reduction algorithms look at all possible input values and reduce the system to allow it to respond to those possible inputs. The reduction occurs by virtue of the limitation on the possible inputs. See J.E. Hopcroft in "An n log n Algorithm for Minimizing the States in a Finite Automaton", Theory of Machines and Computations, (Kohavi, Paz, eds.) Academic Press, pp. 189-196. Our reduction is improved in that we look at the possible inputs at the various states of the FSM. Since not all inputs are possible at all of ths states, the reduction that we achieve by considering individual states may be substantially greater than that which is available conventionally.

In summary, the way the analyzer/developer structure works is that the user specifies the general architecture, functionality for the components, and the tasks. The analyzer/developer then verifies that the tasks can be performed and allows the user to iteratively refine the system definition and the tasks to be performed by the refined system.

The difference between the top-down stepwise refinement approach of this invention and the conventional development approach is that the conventional development approach creates modules, one at a time, with complete functionality within each module. As new modules are added, new behaviors are added to the system. In accordance with this invention, on the other hand, the entire system is defined ab initio; first at a very abstract level and then at levels of increasing detail. Because at the highest level the system is very abstract, low level questions such as pertaining to checking correctness of the syntax of a datum, are left nondeterministic. For example, at the high level of specification a particular message could nondeterministically have good syntax or bad syntax. Both are possible. This is refined in subsequent levels to a system in which the syntax is defined and checked to yield the condition that a particular message will have either good syntax or bad syntax, but not both.

Viewed still differently, in accordance with this invention behaviors are removed rather than added. This distinction is particularly salient because when one expects to be able to prove something about the system as it is being developed, it is not possible to prove something about the behavior of a system when behaviors are added. The reason for that when something is proven about a component and then behaviors are added, it is no longer possible to know whether the previously proven proposition still holds. On the other hand, when behaviors are removed and it has been proved that all the behaviors of the abstract system are satisfactory, then it certainly remains true about the refined system of fewer behaviors. As a result, one important benefit of the approach of this invention is that it enables the user to detect fundamental designer errors at a very early time in development rather than having to wait until the full instantiations of all the elements of all the component is complete.