Analytical development and verification of control-intensive systems

Abstract

Designs are created through 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, 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 implementation 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. In another embodiment, the code is used to create a "net list" for manufacturing the specified system.

Description

BACKGROUND OF THE INVENTION

This invention relates to control-intensive systems, 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 or 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 of 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 verification 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 respective 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 values 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 large 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.sup.10.spsp.4 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.sup.10.sbsb.4 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 design 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 implementation 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 indicated 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 target finite 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 analyzer/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 development 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 properly 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 internal 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 analyzes the refinement in the system specification provided by the user to determine that the refined specification s 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 intergrated 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-storage 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 analyzes 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 flock 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 successful 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 "MSG" when that action occurs. FIG. 3 also indicates that there exists a mapping .PHI. from 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 .PHI. is such that

.PHI.(state in Level 2)>state in Level 1, and .PHI.(action 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 predicate 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 go 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.sub.i is associated with a task T.sub.i. With respect to task T.sub.i the correctness of system operation can be ascertained by determining whether the task is performed by the reduced version as defined by reduction R.sub.i.

The reductions of block 24 are verified vis-a-vis the system definition provided by block 15. This verification 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 and 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 specified 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", published 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 generalized 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 the 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 sent 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, 240, 250, and 290. On 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 subtasks, a much larger portion of the system may be encompassed in the reduced blocks. The resulting simpler system can then be analyzed 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 bock 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 s/r 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 machines 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 component finite 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 states 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 the 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. 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 lookup 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. Practically, 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 Automation", 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 the 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 th 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 bas 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 is 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 components is complete. ##SPC1##

Subject: Analysis of Discrete Event Coordination

1. Introduction

Continuous-time processes such as asynchronous distributed controllers as well as intrinsically discrete-time distributed processes may coordinate according to discrete events. When such coordination is a significant factor in a system's behavior, its analysis can be extremely difficult in practice: whereas conventional computer programs are serial and deterministic, distributed programs involve branching created by parallelism and non-determinism, resulting in a diversity of possible behaviors which grows geometrically with increasing time.

Formal verification of such processes has been thrust to the forefront by researchers interested in the problem of how to develop control-intensive computer hardware and software so that it works properly. The primary basis for this thrust is the failure of classical methods centered around simulation to cope with increasingly complex coordination problems, brought on by asynchrony and distributed control. It is now standard among theoreticians to analyze such coordination in the context of formal assertions founded in logic, formal language theory and general mathematical reasoning, employing a variety of modelling paradigms such as finite state machines, Petri nets, process algebras, partial orders and so on. Given a modelling paradigm and a formal assertion context such as logic or language theory, a relationship is drawn between the assertion context and the modelling paradigm, in order through formal assertions to draw conclusions about the models. While recent work has spawned a large number of interesting and varied ideas, only a very small number of these truly address the original problem of developing properly functioning programs.

The reason for this seems to be that in order truly to address this problem, one needs a methodology which embraces three objectives simultaneously: formal verification, complexity management and formal refinement, as follows. Formal verification, the basis upon which one determines whether development objectives have been met, has a utility which may be measured by expressiveness (what class of properties can be verified), mitigated by the complexity of the verification methodology. There may be a tradeoff between expressiveness and complexity: the more expressive the formal framework, the more complex and hence less useful the methodology. To address the original problem as a practical matter, one seeks the most expressive framework in which one can deal with verification tractably in a largely algorithmic fashion. As the formal framework in any case introduces a high level of complexity, there must be techniques built into the methodology which can circumvent this complexity; otherwise, the methodology is intractable and the original problem remains unsolved. Finally, to solve the original problem, one needs a methodology to map a design specification to an implementation. Such a mapping, commonly known as a refinement mapping, is needed to guarantee that properties verified in a design remain true in an implementation. (Practice has shown that the process of implementation of a design is no less a source of errors than conceptual flaws in the design itself.) These three objectives: verification, complexity management and refinement are like three legs of a stool supporting development of properly functioning hardware and software; less any leg, the support is questionable.

This paper presents a methodology founded in automata theory which encompasses verification, complexity management and refinement. Verification is cast in terms of testing whether the formal language (D) of a design specification D is contained in the formal language (T) of a "task" T which is to be performed by the design. Complexity management and refinement both are cast in terms of transformations called "reductions". Design specifications D are modelled by state machines, while tasks T are defined by automata.

In order to test whether (D) (T), one may reduce D, relative to T, to a less complex D' with an associated less complex T' such that

(D') (T')> (D) (T). (1,1) The reduction of D to D', in that it is relative to the task T to be verified, is significantly more powerful than equivalence and minimization. For example, suppose that T refers only the parity of outputs 1, . . . , N of D; then, in order to test whether D performs the task T, D may be simplified by abstracting its N output values to 2 values: (odd and even), although this reduction of D is not equivalent to D and D may be minimal up to equivalence.

The basic concept of "reduction" is as old as mathematics: reduce the amount of effort needed to prove a result by eliminating extraneous or redundant details. To one extent or another, it is used in most actual efforts concerned with the analysis or simulation of real systems. However, it is important to give this basic concept a precise embodiment, whose validity can be verified algorithmically. In this paper, the reduction transformation D.fwdarw.D' is presented in the form of a formal language homomorphism, whose validity can be verified in time linear in the size of components of D, and the number of such components.

It is shown furthermore that refinement is simply inverse reduction, and thus is handled through the same mechanism. In (1.1), if D' is a design, if D is an implementation of D', if T' is a task verified for the design D' and if T is the naturally induced image of T' under the refinement transformation D'.fwdarw.D, then the relation (1.1) means that tasks verified for the design remain valid for the implementation. In practice, a design may undergo a succession of refinements, each step refining or "implementing" the "design" of the previous step, consistent with (1.1). By transitivity of such stepwise refinement, (1.1) obtains when D is the ultimate implementation and D' is any design in the refinement hierarchy, verified for any task T' defined at the "level" of D'.

Because of the very large complexity associated with real designs, even defining the reduction homomorphism D.fwdarw.D' directly may well be intractable, simply on account of the size of D. This problem can be circumvented by defining the homomorphism D.fwdarw.D' indirectly in terms of homomorphisms on components of D. If D may be factored as D=D.sub.1 . . . D.sub.k and D' likewise factored as D'=D.sub.1 ' . . . D.sub.k ', then it is shown that the existence of component homomorphisms .PHI..sub.i :D.sub.i .fwdarw.D.sub.i ' for i=1, . . . k imply the existence of a product homomorphism ##EQU1## Although the size of D grows geometrically with k, the complexity of verifying that each .PHI..sub.i has the required properties is only linear in the size of D.sub.i.

In order to carry out a program for the mutual support of formal verification, reduction and refinement as above, it is important to have a close relationship between the formal assertion context used for verification (say, logic or automata theory) and the modelling paradigm used to represent the design specification. Without such a close relationship, methodologies for reduction and refinement may be difficult to discern. Specifically, if the modelling paradigm and the assertion context are not closely related, it may be difficult to relate transformations in the former to transformations in the latter in such a way that an assertion valid for a model transforms to an assertion valid for the transformed model.

As already indicated, this paper adopts the modelling paradigm of finite state machines, using formal assertions founded in automata theory. Finite state machines are bound closely to automata through their respective languages and the similarities of their generators, both given in terms of finite directed graphs. Just how this close relationship affords a tractable theory for reduction and refinement is the subject of this paper. It should be conceded that the regular languages generated by automata are not sufficiently expressive to capture assertions dealing with the correctness of many distributed algorithms, such as those employing recursion and induction. However, verification of such algorithms is problematic in any context, and there is much debate concerning which really have been proved, or even what is a proof [Ba89]. Therefore, there may be some justification to the contention that regular (and.omega.-regular) assertions encompass the major portion of assertions admitting widely acceptable proofs. If this is the case, it may be futile to adopt a more powerful context for formal assertions, only to find that widely believed proofs (or any proofs at all) are few and far between. On the other hand, automata theory admits certain weak forms of induction [KM89], as well as a context in which to reason about parameterized automata and state machines. This affords a framework in which certain non-regular assertions can be reduced to regular assertions, or at least reasoned about to the extent they may be reasoned about in any other context. While there has been only preliminary thinking in this direction, it may hold a promise for extending automata theory to effectively computable results. In any case, since a Turning machine is an infinite state automaton (with bounded state transitions), all recursively enumerable assertions may be expressed in this context (although not necessarily decided).

In order to facilitate the treatment of state machine models in the context of assertions defined by automata, it has been convenient to alter slightly the standard definitions of both, and present each through a uniform context of enabling transition predicates, non-deterministic outputs (for state machines) and a new acceptance condition (for .omega.-automata). The enabling transition predicates (Boolean functions of inputs and outputs) combine (through Boolean conjunction, disjunction and negation) to form a Boolean algebra basic to the theory of reduction developed here. State machines are taken to be essentially Moore machines, but unlike Moore machines, the state machines used here are endowed with non-deterministic outputs. This non-determinism is important for several reasons. First of all, it provides a necessary mechanism to introduce uncertainty or variety into a design, allowing designs to be specified as closed systems, containing all "input" and "output" within. (This is basic to the analysis described here.) Nondeterminism also may be used to model incompletely defined response, indeterminate delay and actions whose control is external to the model (and thus unknown, but for their effect). Furthermore, non-determinism affords a "place-keeping" mechanism for refinement: details to be added at a later point in development may be modelled non-deterministically in the high-level design. Finally, non-determinism affords an important reduction mechanism; a deterministic state machine D may be replaced by a non-deterministic state machine D' with fewer states and larger language over the same alphabet; if such a reduced machine D' were shown to have a certain (.omega.-) regular language property T, then in the sense of (1.1), the original machine would have that property T as well (although the reduced machine and the original machine may by no means be equivalent in any general sense). Such a reduced D' may be obtained by "freeing" a state machine component D.sub.i of D (cf. (1.2) by replacing D.sub.1 with D.sub.1 ' where D.sub.1 ' has a single state from which it non-deterministically outputs all the outputs of D.sub.1. Finally, while a Moore machine with non-deterministic transitions cannot (in general) be determinized, allowing non-deterministic outputs is enough to be able to determinize the transitions of the machine, an important step in many procedures.

The Boolean algebra generated by transition predicates affords a basis for decomposition of state machines. It turns out that a state machine can be represented by a matrix over this Boolean algebra in such a way that decomposition of the state machine into coordinating component machines is represented by the tensor product of the matrices associated with each component machine. This decomposition is essential for verification of reduction and refinement, which must be accomplished component-wise in large systems. Conventional homomorphism of Boolean algebras gives rise to the language homomorphisms used in the theory developed here.

Formal assertions about state machine models are given here in terms of infinitary (.omega.-regular) automata. Such automata, while generally applied to reasoning about non-terminating processes, apply as well to terminating processes, through concatenation of an infinite tail of "null" symbols to each finite prefix; thus, there is no reason to deal with languages comprised of both (finite) strings and (infinite) sequences together as is commonly done: sequences alone suffice to model both. Like the state machines, the .omega.-automata used here, the L-automata defined over the Boolean algebra L. comprise a slight variation on standard .omega.-automata. In addition to being defined in terms of the same underlying transition structure and Boolean algebra L as the state machines, they have two acceptance conditions which in an intuitive sense, may be associated, one with "fairness" or "liveness" and the other with "safety" and "eventuality" properties, as they are often understood. While experience [HK90] has indicated the practical utility of this definition with regard to specifying tasks, perhaps more important is that it gives rise to a decomposition technique in which any .omega.-regular property can be built up from smaller, more easily testable properties.

Classically, given automata .LAMBDA. and .GAMMA., in order to test whether .LAMBDA. (.GAMMA.), one first constructs an automaton .GAMMA. which defines the complementary language (.GAMMA.)', then one constructs an automaton .LAMBDA.8.GAMMA. satisfying .LAMBDA.8.GAMMA.= (.LAMBDA..andgate. (.GAMMA.) and finally one tests whether (.LAMBDA.8.GAMMA.)=.phi.. This entire procedure is at least as complicated as constructing .GAMMA., and since .LAMBDA. may be taken to define all sequences (over the given alphabet), testing language containment is at least as hard as testing whether (.GAMMA.)=.phi., the so-called "emptiness of complement" problem. This problem is PSPACE-complete in the number of states for non-deterministic Buchi automata [SVW85], while deterministic Buchi automata are strictly less expressive than non-deterministic Buchi automata.

On the other hand, given an .omega.-regular language , a finite number of deterministic L-automata .GAMMA..sub.1, . . . , .GAMMA..sub.n may be found such that ##EQU2## (This is not true for Buchi automata.) In order to test (.LAMBDA.) , one tests (.LAMBDA.) (.GAMMA..sub.i) for i=1, . . . , n. Each test (.LAMBDA.) (.GAMMA..sub.i) may be completed in time linear in the number of edges of .LAMBDA. and linear in the number of edges of .GAMMA..sub.i [Ku87]. Not only do the several individual tests (.LAMBDA.) (.GAMMA..sub.i), i=1, . . . , n defined by the task decomposition ##EQU3## provide a test which is more tractable in bounded space than the single test (.LAMBDA.) , but it provides a greater potential for reduction; each test (.LAMBDA.) (.GAMMA..sub.i) may be separately reducible to a test (.LAMBDA..sub.i ') (.GAMMA..sub.i '), with each .GAMMA..sub.i 'different for different i.

2. Preliminaries

Conventionally, the transition structure of a state machine or automaton is viewed dynamically in terms of a "successor" relation on a set of states; this relation defines a "next" state (for deterministic structures) or in general, a set of next states, for each "current" state and "input". I prefer to view a transition structure statically as a directed graph whose vertices correspond to states and whose edges are labelled respectively with the set of input values which enable the associated state transition (cf. [Ts59]). The labelled graph is defined by its "labelled" adjacency matrix, whose ij-th element is the label on the edge from vertex i to vertex j. We will see that this provides a more convenient notation for combining transition structures than the dynamic definition. Furthermore, it turns out to be natural and useful to impose an algebraic structure on the inputs. Specifically, inputs are manipulated through predicates over input tokens. These predicates, which naturally form a Boolean algebra (a set closed under conjunction, disjunction and negation), provide a succinct means to represent sets of input values. For example, if inputs (say, from two sources) are represented in terms of the respective values of variables x and y, the enabling predicate for a certain transition may be represented syntactically as "x<y", denoting the set of all input pairs satisfying that relation. If L is the Boolean algebra of such predicates (semantically, the set of all subsets of inputs), then a transition structure is a square matrix over L. Conversely, for any Boolean algebra L, a square matrix over L may be interpreted as a transition structure for the set of inputs represented by the atoms of L (see below).

2.1 Boolean Algebra

Let L be a Boolean algebra, with meet (disjunction, product) *, join (conjunction, sum) +, complement .about., multiplicative identity 1 and additive identity 0 [Ha74]. A Boolean algebra admits of a partial order .ltoreq. defined by x.ltoreq.y iff x*y=x. If x.ltoreq.y and x.noteq.y, write x<y. Atoms are minimal elements with respect to this order. A Boolean algebra is said to be atomic if every non-zero element majorizes an atom. In this case every non-zero element can be expressed as a sum of atoms in a unique way. In this paper, every Boolean algebra L is assumed to be atomic (it is certainly true if L is finite). Let S(L) denote the set of atoms of the Boolean algebra L. For the purposes of this paper, little is lost if one thinks of L as 2.sup.s, the power field over S, which is the set of all subsets of a finite set S (the "alphabet") where 1=S, 0=.phi., 8 is set intersection, + is set union and .about. is set complementation in S; the atoms of L in this case are the (singleton sets comprised of) the elements of S. A homomorphism of Boolean algebras is a map which is linear with respect to *, + and .about. (i.e., .phi.(x*y)=.phi.(x)8.phi.(y), .phi.(x+y)=.phi.(x)+.phi.(y) and .phi.(.about.x)=.about..phi.(x)). Any homomorphism is order-preserving (x<y>.phi.(x)<.phi.(y)). Every Boolean algebra contains as a subalgebra the trivial Boolean algebra ={0,1}. If S L is a subset of L, [S] is defined to be the smallest subalgebra of L containing S. A sum or product indexed over the empty set is 0, 1 respectively.

Suppose L.sub.1, . . . , L.sub.k are subalgebras of a Boolean algebra L. Define ##EQU4## It is easily checked that .pi.L.sub.i is a subalgebra of L, in fact .pi.L.sub.i = [.orgate.L.sub.i ]. It is easily seen that S(.pi.L.sub.i)={s.sub.1 * . . . *s.sub.k .vertline.s.sub.i S(L.sub.i), 1.ltoreq.i.ltoreq.k} {0}. Say L.sub.1. . . , L.sub.k are independent if 0.noteq.x.sub.i L.sub.i for i=1, . . . , k>x.sub.1 8 . . . x.sub.k .noteq.0. Clearly, L.sub.1, . . . , L.sub.k are independent if and only if S(.pi.L.sub.i)={s.sub.1 8 . . . *s.sub.k .vertline.s.sub.i S(L.sub.i), 1.ltoreq.i.ltoreq.k}. Write L.sub.1.L.sub.2. . . . . L.sub.k =.pi.L.sub.i.

2.2 L-Matrix; Graph

Let L be a Boolean algebra, let V by a non-empty set and let M be a map

M:V.sup.2 .fwdarw.L (where V.sup.2 =V.times.V is the Cartesian product). Then M is said to be an L-matrix with state space V(M)=V. The elements of V(M) are said to be states or vertices of M. An edge of an L-matrix M is an element e V(M).sup.2 for which M(e).noteq.0. (M(e) is the "label" on the edge e.) The set of edges of M is denoted by E(M). If e=(v,w) E(M), let e.sup.- =v and e.sup.+ =w. If M is an L-matrix and L L' then M is an L'-matrix as well.

An L-matrix provides the transition structure for a state machine or automaton. In automata-theoretic terms, the "alphabet" is the set of atoms S(L) and an "edge label" M(e) L of an L-matrix M represents the set of atoms .lambda.={s S(L).vertline.s.ltoreq.M(e)} which enable the transition along the edge e, since ##EQU5## Since any two distinct atoms s,t S(L) satisfy s*t=0, M is "deterministic" if for each state v and each "input letter" s S(L), s.ltoreq.M(v,w) for at most one w V(M). Likewise, M is "complete" if for each v V(M) and each s S(L), s.ltoreq.M(v,w) for some w V(M). This is recapitulated below.

An L-matrix M is deterministic if for all u,v,w V(M), v.noteq.w>M(u,v)*M(u,w)=0. An L-matrix M is complete if for all v V(M) the sum ##EQU6## If G is an L-matrix and W V(G), then G.vertline..sub.w, the restriction of G to W, is the L-matrix defined by V(G.vertline..sub.w)=W and G.vertline..sub.w (e)=G(e) for all e W.sup.2.

A graph is a -matrix. The graph of the L-matrix is the graph M with state space V(M)=V(M), defined by ##EQU7##

A path in a graph G of length n is an (n+1)-tuple v=(v.sub.0, . . . , v.sub.n) V(G).sup.n+1 such that G(v.sub.i,v.sub.i+1)=1 for all 0.ltoreq.i<n; the path v is a cycle if vv.sub.n =v.sub.0. The path v is said to be from v.sub.0 to v.sub.n.The path v contains the edge (v, w) E(G) if for some i, 0.ltoreq.i<n, v.sub.i =v and v.sub.i+1 =w. If C V(G) and each v.sub.i C, then v is in C. A cycle (v,v) of length 1 is called a self-loop (at v). A vertex v V(G) is reachable from I V(G) if for some v.sub.0 I, there is a path in G from v.sub.0 to v. Any statement about a "path" in a L-matrix M is to be construed as a statement about that path in M.

Given an L-matrix M, a sequence x L.sup..omega. (a sequence, by definition, is infinite) and a sequence of states v V(M).sup..omega., say v is a run (in M) of x from v V(M) provided v.sub.0 =v and x.sub.i *M(v.sub.i,v.sub.i+1).noteq.0 for all i.

Let G be a graph. A set C V(G) containing more than one element is said to be strongly connected provided for each pair of distinct elements v, w C there is a path from v to w. A singleton set {v} V(G) is strongly connected if (v,v) E(G). A maximal strongly connected set is called a strongly connected component (of G). Clearly, for every graph G, V(G) is uniquely partitioned into strongly connected components and a non-strongly connected set, each vertex of which has no self-loop. (The requirement that a single vertex have a self-loop in order to be strongly connected, at some variance with the customary definition, is important to the theory developed here.)

Let G,H be graphs and let .PHI.:V(G).fwdarw.V(H) be a map which satisfies (v,w) E(G)>(.PHI.(v),.PHI.(w)) E(H). Then .PHI. extends to a map .PHI.: E(G).fwdarw.E(H) and we say .PHI. is a homomorphism from G to H, and write

.PHI.:G.fwdarw.H.

Let M and N be L-matrices. Their direct sum is the L-matrix M.sym.N with V(M.sym.N)=V(M).orgate.V(N), defined by ##EQU8## their tensor product is the L-matrix M N with V(M N)=V(M).times.V(N), defined by

(M N)((v,w),(v',w'))=M(v,v')*N(w,w'). The direct sum and tensor product can be extended to a commutative, associative sum and an associative product, respectively, of any finite number of L-matrices. If L is complete (i.e., closed under infinite sums and products), the direct sum and tensor product can be extended to infinite sums and products as well. Lemms: The tensor product of deterministic L-matrices is deterministic. The tensor product of complete L-matrices is complete. Proof: Let u, v, w V(M) and u', v', w' V(N). Then ##EQU9## If (w,w').noteq.(u,u') and M, N are deterministic, then either the left factor or the right factor must be zero, and it follows that M N is deterministic. If M, N are complete then ##EQU10## and it follows that M N is complete

Let G, H be graphs. The projection

.pi..sub.G :V(G H).fwdarw.V(G) induces a (not necessarily onto) projection .pi..sub.G :E(G H).fwdarw.E(G). If G and H are matrices, .pi..sub.G will denote the projection on the underlying graph G. Given G.sub.1, G.sub.2, . . . , the projections .pi..sub.G.sbsb.i may be written as .pi..sub.i, for convenience.

3. L-Automata

Finite state automata which accept sequences (rather than strings) define the .omega.-regular languages. This class of automata is established as a model in logic, topology, game theory and computer science [Bu62, Ra69, Ra72, Ch74, Ku87a, SVW85, etc.]. In computer science, such automata can be used to model non-terminating processes such as communication protocols and integrated hardware systems [AKS83, DC85, Ku85, BC87, KM90, etc.], as well as terminating processes, as already explained. Several different types of such automata have been proposed [Ch74, Sa88], distinguished by the condition under which a "run" of the automaton is accepted. While each type of automaton is well-suited to various applications, none proved well-suited for the reductions described here. A new type of automaton [Ku87] proved better-suited, for reasons described in the introduction.

An L-automaton is a 4-tuple

.GAMMA.=(M.sub..GAMMA., I(.GAMMA.), R(.GAMMA.), Z(.GAMMA.)) where M.sub..GAMMA., the transition matrix of .GAMMA., is a complete L-matrix, .phi..noteq.I(.GAMMA.) V(M.sub..GAMMA.), the initial states of .GAMMA., R(.GAMMA.) E(M.sub..GAMMA.), the recurring edges of .GAMMA. and Z(.GAMMA.) 2.sup.V(M.GAMMA.), the cycle sets of .GAMMA., is a (possibly empty) set of non-empty subsets of V(M.sub..GAMMA.). Set V(.GAMMA.)=V(M.sub..GAMMA.), E(.GAMMA.)=E(M.sub..GAMMA.) and .GAMMA.(v,w)=M.sub..GAMMA. (v,w) for all v,w V(.GAMMA.). Let R.sup.- (.GAMMA.)={e.sup.- .vertline.e R(.GAMMA.)} and R.sup.+ (.GAMMA.)={e.sup.+ .vertline.e R(.GAMMA.)}. Define the graph of .GAMMA.,.GAMMA.=M.sub..GAMMA.. Let .vertline..GAMMA..vertline.=cardV(.GAMMA.).

A sequence of states v=(v.sub.0, v.sub.1, . . . ) V(.GAMMA.).sup..omega. is .GAMMA.-cyclic if for some integer N and some C Z(.GAMMA.), v.sub.i C for all i>N, while v is .GAMMA.-recurring if {i.vertline.(v.sub.i,v.sub.i+1) R(.GAMMA.)} is infinite. A sequence of atoms x S(L).sup..omega. is accepted by, or is a tape of .GAMMA. provided x has a .GAMMA.-cyclic or .GAMMA.-recurring run from an initial state. Such a run is an accepting run (of x). The set of tapes of .GAMMA., (.GAMMA.), is defined to be the language of (or accepted by) .GAMMA.. Two L-automata .GAMMA. and .GAMMA.' are said to be equivalent if (.GAMMA.)= (.GAMMA.'). A chain of .GAMMA. is a pair (v,x) where v is an accepting run of a tape x. Let (.GAMMA.) denote the set of chains in .GAMMA..

The L-automaton .GAMMA. is said to be deterministic if M.sub..GAMMA. is deterministic; if .GAMMA. is deterministic and .vertline.I(.GAMMA.).vertline.=1 then .GAMMA. is said to be strongly deterministic. (Customarily, "deterministic" has been used in the literature to mean what is here called "strongly deterministic"; however, strong determinism often leads to unnecessary restriction, for example, in automata complementation and minimization, where only determinism is required.)

(3.1) Lemma: A tape accepted by a strongly deterministic L-automaton has a unique accepting run.

Relationships between L-automata and other types of automata are given in [Ku87].

4. L-Process

Evidently, L-automata are not directly suited to define coordinating discrete event systems, as there is no direct way to capture "coordination" of L-automata: they have no outputs, and hence no way to communicate. Instead, a coordinating discrete-event system may be built up from Moore machines, the outputs of each machine providing inputs to various machines. This provides a "data-flow" context [WA85] in which the system is represented by the collection of coordinating machines.

For our purposes here, as already explained in section 1, Moore machines are not quite adequate, on account of their determinism. On the other hand, merely to allow a Moore machine to be non-deterministic is not the answer: a deterministic transition structure is important to be able to compare machines. (Note that a non-deterministic Moore machine may not be determinizable.) Comparison is used to show that one machine abstracts or implements another, for purposes of reduction and refinement. Furthermore, it turns out to be convenient to be able to incorporate fairness constraints directly into the machine definition, rather than through other devices (such as L-automata) which may increase the size of the state space and thus the complexity of verification.

For these reasons, a process is modelled as a Moore-like machine which may at once have non-deterministic outputs and a deterministic transition structure, and incorporate fairness constraints without increasing the size of the state space. Thus, while at each state a Moore machine produces an output as a function of that state, the L-process defined below may produce non-deterministically one of several outputs possible from each state (the set of outputs possible form a state is a function of the state). While the transition structure of an L-process may be deterministic or non-deterministic, it may be determinized through the Rabin-scott subset construction. Although formally an L-process, like an L-automaton, is defined statically, it has a dynamic interpretation: an L-process recursively "selects" an output allowed from the current state and then "resolves" that selection by changing state along a transition enabled by that selection. This dynamic interpretation is the selection/resolution (or s/r) model of coordination proposed by B. Gopinath and this author in 1980 [GK80] and illustrated in [AKS83, Ku85] for modelling communication protocols and more general distributed discrete-event systems. More generally, a " system" is comprised of several L-processes, the selections (outputs) of some providing the "inputs" to others. While the dynamic interpretation is convenient conceptually, as with L-automata, a static definition turns out to be more useful for analysis.

Let L be a Boolean algebra. An L-process A is a 5-tuple

A=(M.sub.A,S.sub.A,I(A),R(A),Z(A)) where M.sub.A, I(A), R(A) and Z(A) are as in the definition of L-automaton, except that M.sub.A is not required to be complete; S.sub.A, the selector of A, is a function S.sub.A :V(A).fwdarw.2.sup.L from the states of A to the set of subsets of L, such that for each v V(A), the set of selections of A at v, S.sub.A (v).noteq..phi., and for all v, w V(A), ##EQU11## (The condition (4.1) is explained below.) Let ##EQU12## the set of selections of A, and set .vertline.A.vertline.=card V(A). Say that an L-process A is atomic if each selection x S(A) is an atom in the Boolean algebra [S(A)] generated by the set of selections of A. Thus, A is atomic iff for any selections x,y S(A), x*Y.noteq.0 x=y. An assumption of process atomicity does not compromise expressiveness, and turns out to be fundamental in the analysis of coordination (cf. (4.10) below). therefore, this paper focuses mainly on atomic processes. Fortunately, atomicity is preserved under combining "independent" processes (4.8, below).

A selection x S.sub.A (v) enables the state transition (v, w) provided x*A(v w).noteq.0, i.e., provided that x and the transition predicate A(v, w) are jointly satisfiable. The condition (4.1) may be interpreted as meaning that every edge from a state v is enabled by some selection from v(i.e., some x S.sub.A (v)). (This may be enforced by replacing each edge label A(v, w) by ##EQU13## This is a technical assumption needed to relate the "language" of A to the language of a derived L-automaton; clearly, it does not limit the expressiveness of L-processes, as a transition from v enabled by no selection from v is never crossed. Note that a condition equivalent to (4.1) is: for all v V(A), ##EQU14## If in fact equality holds in (4.2) for all v and 0 S(A), then A is said to be lockup-free. (This is related to completeness for L-automata, if we consider an L-automaton to be an L-process which has the single selection 1 L from each state.) If A is lockup-free, then for each selection x S.sub.A (v)J, some transition out of v is enabled by x, i.e., x*A(v,w).noteq.0 for some w V(A). However, equality in (4.2) is stronger than this condition. The problem with this weaker condition is that it is not preserved under products. Since in a strong sense a lockup is a defect in definition, we would like lockup-free components to combine to form a lockup-free system.

Thus far, the transition structure of an L-process has been defined statically and interpreted dynamically. Now, the "behavior" or language of an L-process is defined. While sometimes the "language" of a Moore machine is defined to be the set of all its possible productions (output sequences) this in fact is an inadequate definition, in that it masks the essential relationship between input and output. Rather, in dynamic terms, the language of an L-process is defined to be all sequences of input-output pairs, except for those sequences "ruled out" by the "fairness" constraints. More generally, since a "system" may comprise several L-processes, and the inputs of each process are taken from the selections of other processes, it is most suitable to cast the language of a process in terms of the selections of the system.

Let x S(L).sup..omega. (the set of all sequences of atoms of L), and let A be an L-process. A run of x in A is a run v of x in M.sub.A with v.sub.0 I(A). Say x is a tape of A if it admits of a run v in A which satisfies:

for some N>0, i>N>(v.sub.i,v.sub.i+1) R(A); (4.3) for each C Z(A) and each i>0 there exists j>i such that v.sub.j C. (4.4) Such a run v is said to be an accepting run of x. The language of A, denoted (A), is the set of all tapes of A. Two L-processes A and A' are equivalent if (A)= (A').

A chain of an L-process A is a pair (v,x) where x (A) and v is an accepting run of x in A. Let (A) denote the set of chains of A.

Notice that (4.3) and (4.4) are the negation of the corresponding definitions for an L-automaton. The reason is that R(A) and Z(A) are used in L-processes to define "fairness" constraints: behaviors which are most conveniently and most often expressed negatively (e.g., "A will not forever remain in its `critical section` states (designated by a cycle set"). Note, however, that there is no intrinsic notion of "fairness": any .omega.-regular property may be represented, as shown in (4.5).

An L-process A is said to have deterministic resolutions if M.sub.A is deterministic.

(4.5) Proposition: Let L be a Boolean algebra and let be an arbitrary .omega.-regular language over S(L). There exists an L-process A with deterministic resolutions satisfying (A)=

Proof: Let .LAMBDA..sub.i, . . . , .LAMBDA..sub.i be strongly deterministic L-automata satisfying .andgate. (.LAMBDA..sub.i)= [Ku87: Thm. 3; Cor. to Prop. 2]. Define L-processes P.sub.1, . . . , P.sub.k by P.sub.i =M.sub..LAMBDA..sbsb.i,1,I(.LAMBDA..sub.i),R(.LAMBDA..sub.i), Z(.LAMBDA..sub.i)) where 1(v)={1} for all v V(.LAMBDA..sub.i). By (3.1), (P.sub.i)= (.LAMBDA..sub.i)'. Set P=(.sym.M.sub.P.sbsb.i,1,.orgate.I(P.sub.i),.orgate.R(P.sub.i), .orgate.Z(P.sub.i)). Then (P)=.orgate. (P.sub.i)=.orgate. (.LAMBDA..sub.i)'=

In the literature one often finds "process behavior" defined both in terms of (infinite) sequences and (finite) strings. This is an unnecessary complication. If a process models a program which terminates, there is no harm in modelling "termination" as a state in which the process can only self-loop, remaining forever after in that state and selecting thereafter a "null" selection which enables no non-self-loop of any process in the system. On the other hand, if a process terminates on account of a lockup, the view taken here is that this is a defect in the definition: what happens next is undefined. (it is often convenient purposely to introduce lockups in processes which are implemented on a computer, as a practical means to determine if the lockup condition is every reached, in which case the computer should return an `error`.)

Given an L-process A, the reachable subprocess of A is the L-process A* defined as the restriction of A to the set of states reachable from I(A). Certainly (A*)= (A).

Let A be an L-process. Define the L-automaton A# as follows: V(A#)=V(A).orgate.{#} where # is a symbol not in V(A);I(A#)=I(A); for v, w V(A).

A#(v,w)=A(v,w) while ##EQU15## A#(#,#)=1, A#(#,v)=0; R(A#)=.phi., Z(A#)={V(A)}. Say that an L=process A is full if R(A)=.phi. and Z(A)={.phi.}; if A is full then no runs of the transition matrix of A are "unfair" and (A)= (A#).

Recall that a regular language C over .SIGMA. is said to be prefix-closed if for all x,y .SIGMA.*, xy C>x C. The limit of a language C is defined to be the .omega.-language

lim C.ident.{x .SIGMA..sup..omega. .vertline.for all i.sub.1 <i.sub.2 <. . . , (x.sub.0,x.sub.1,x.sub.2, . . . , x.sub.i.sbsb.j) C for all j}. (4.6) Theorem: Let L be a Boolean algebra and let .noteq..phi. be an .omega.-regular language over S(L). Then the following are equivalent: 1. = (A#) for some (lockup-free) L-process A; 2. =lim C for some regular prefix-closed C over S(L). Proof: 1.>2.: Let C be the (regular) language accepted by the Rabin-Scott acceptor defined by M=(M.sub.A #, I(A), V(A)) (here V(A) is the set of "final" states). If x (A#) then for all i x.sub.0. . . x.sub.i (M) so (A#) lim C. If x lim C then x.sub.0. . . x.sub.i.sbsb.j (M) for j=1, 2, . . . . Since there is no outgoing edge from the state x V(M), x (A#). Thus = (A#)=C. By construction, C is prefix-closed. 2.>1. Let M=(M,I,F) be a deterministic Rabin-Scott acceptor [RS59] with (M)=C. Since C is prefix-closed, there can be no transition form a state of F' (.ident.V(M) F) to a state of F. Let A be the full L-process with V(A)=V(M) F', M.sub.A =M.vertline..sub.V(A),I(A)=I(M) F' and ##EQU16## Then ##EQU17## w V(A);x*M(v, w).noteq.0) and since M is deterministic, this sum is equal to ##EQU18## therefore, A is a lockup-free L-process. Since A is full, (A#)=C= .

Given L-processes A.sub.1, . . . , A.sub.k define their (tensor) product to be ##EQU19## (4.7) Lemma: If A.sub.1, . . . , A.sub.k are L-processes, then their product A.sub.i is an L-process.

The L-processes A.sub.1, . . . , A.sub.k are said to be independent provided

x.sub.i S(A.sub.i), (i=1, . . . , k)>x.sub.1 * . . . *x.sub.k .noteq.0. (4.8) Proposition: If A.sub.1, . . . , A.sub.k are [atomic and] independent, lockup-free L-processes, then their product A.sub.i is [respectively, atomic and] lockup-free. (4.9) Proposition: Let A.sub.1, . . . , A.sub.k be independent, lockup-free L-processes. Then. ##EQU20## It follows directly from (4.9.1) that A.sub.i *)= A.sub.i)*).

The discrete-event coordination in a "system" of atomic, independent, lockup-free L-processes A.sub.1, . . . , A.sub.k is modelled by the behavior of the product L-process A=A.sub.1 . . . A.sub.k. Interpreting this system dynamically, at each time, in each process A.sub.i, a selection x.sub.i possible at the "current" state v.sub.i (i.e., some x.sub.i S.sub.A.sbsb.i (v.sub.i)) is chosen non-deterministically. The product x=x.sub.1 * . . . *x.sub.k defines a "current global selection", i.e., a selection of the product A at the state v=(v.sub.1, . . . , v.sub.k), with x S.sub.A (v). At each time, in each process, the current global selection determines a set of possible "next" states, namely those states to which the transition from the current state is enabled by the current global selection. IN A.sub.i the transition from state v.sub.i to state w.sub.i is enabled by x iff x*A.sub.i (v.sub.i,w.sub.i).noteq.0. Under appropriate conditions, each process separately may be considered to resolve the current global selection, by choosing (non-deterministically) one of these possible next states. A system of processes progresses in time by each repeatedly "selecting" and "resolving" (cf. FIG. 1). This interpretation correctly describes the behavior of the product if L= [S(A)], since then by the atomicity assumption on each A.sub.i it follows that for v=(v.sub.1, . . . , v.sub.k) and w=(w.sub.1, . . . w.sub.k),

x*A.sub.i (v.sub.i,w.sub.i).noteq.0 for 1.ltoreq.i.ltoreq.k x*A(v,w).noteq.0. (4.10) The assumption that L= [S(A)] provides that S(A) includes all the selections of the "system" which determine the transitions of the component processes. If this is the case, then each A.sub.i is a [S(A)]-process, so one may as well assume that L= [S(A)].

Modelling a hardware or software system by a family of coordinating L-processes A.sub.1, . . . , A.sub.k may be viewed in terms of writing a computer program to implement the functionality of the system, in a programming language in which "process" is a programming primitive. Such a language is intrinsically an automaton data-flow language, in the sense of [WA85], with processes as data nodes, and data-flow determined by the dependency of a process upon the selections of another process. The S/R language [JK86], developed explicitly to implement the s/r model consistently with (4.10), is an example of such a language.

The modelling discipline imposed by the syntax of the S/R language is intrinsically hierarchical in nature, skewed in favor of modelling a system as many small coordinating processes. The simplest processes are ones which play the role of a variable in a conventional program (but rather than being updated through assignment statements, here a "variable" process updates itself as a function of input values). Buffers and other "passive" data structures may be formed as an "array" of such variable processes, i.e., if A.sub.i is a process which models an array element (as a function of the parameter i) then A= A.sub.i is a process which models the array. The "active" (and typically non-deterministic) portions of an S/R program consist of "controller" processes which coordinate the flow of data among the passive data structures. (These controllers correspond to the so-called "state machines" one sometimes finds in conventional programs.) The S/R language lends itself to hierarchical modelling of controller processes as well. Thus, a controller A may be decomposed into several component controllers A.sub.1, . . . , A.sub.k (with A=A.sub.1 . . . A.sub.k), each component controlling some aspect of the data flow, in coordination with the other controllers.

Such a data-flow language directly models hardware architecture, and thus is directly suited to modelling and implementing hardware. Nonetheless, it has been found to be no less suitable for control-intensive software programs such as communication protocols. In fact, on account of the intrinsic parallelism built into programs with distributed control, the fact that the s/r model imposes a "hardware architecture" on S/R programs seems to offer an advantage of modularity and hence clarity over equivalent non-data-flow programs, providing a potential for a dramatic increase in productivity and efficiency [HK90 ].

The dynamic interpretation of the s/r model may be used to model systems of processes coordinating asynchronously in continuous time by interpreting "at each time" for selecting and resolving consistent with (4.10), as meaning "at each real value of time", this provided state transitions are instantaneous and occurring at discrete points of time. (A necessary requirement for this interpretation is that there by no two adjacent states without self-loops.) This approach is expanded in section 5 below.

An L-process A is said to be deterministic if it has deterministic resolutions and for each v V(A), .vertline.S.sub.A (v).vertline.=1; A is said to be strongly deterministic if A is deterministic and .vertline.I(A).vertline.=1. Note that a strongly deterministic L-process A is a Moore machine with input alphabet S(L) and output alphabet S(A), and every Moore machine has this form.

(4.11) Theorem: Every full L-process is equivalent to a full L-process with deterministic resolutions and unique initial state. Proof: Use the Rabin-Scott determinization algorithm [RS59].

5. Modelling Asynchrony

Delay may be modelled by a specific "pause" selection with the property that it does not disable the self-loop of any process in the "system". Upon entering a state, a process first selects "pause", causing the process to "self-loop", and conveying "no information" to any other process. By that, it is meant that no process is forced to change state on account of this "pause". At some future point in time, the process selecting "pause" non-deterministically may change its selection to some other value, enabling certain state changes. In this way, if state changes are interpreted as instantaneous events, then they are separated by a non-zero duration defined by such "pause" selections in one or more components; with this interpretation, the system of processes model discrete events occurring asynchronously in continuous time.

In a data-flow model of asynchronous processes, inter-node delays appear as such "pause" delays within particular "channel" processes (whose function may be simply to model such delay). Thus, the delayed asynchronous coordination of two controllers A and B may be modelled through the introduction of a third "channel" process C with the property that all coordination between A and B is via C. This may be realized as follows. At some point in time A changes its selection from a pause selection to a non-pause selection, say x. The (instantaneous) resolution of x in C is a change of state to a new state of C, let us say state "x". From its (new) state x, C may first select a pause selection, (conceptually) for an amount of time equal to the interprocess delay between A and B; the selection of C then changes (non-deterministically) from "pause" to the selection (say) x'. The resolution in B of x' reflects the passage of the "datum x" from A to B. In this case the process C is not part of the "implemented" program, but only a model of (part of) the environment in which the implemented program resides. (For software, C is "implemented" by the operating system interfaces, while for hardware, C may be implemented by wires or other component interface devices.)

When an S/R program is intended to model asynchrony and other continuous-time evolution, the "realizability" of such a program becomes an issue: there may in fact be no continuous-time implementation of a given program. For example, since state transitions are taken to be instantaneous, there can be no continuous-time implementation of a process having two consecutive states without self-loops. It is important, therefore, to identify a broadly applicable condition which guarantees that an S/R program is realizable.

Given an L-process A with a chain (v,x) (A), a realization of (v,x) is a map

.gamma..sub.v,x : [0, [.fwdarw.V(A).times.S(A) with the property that .gamma..sub.v,x is a step-function (piecewise-constant), with i-th step value (v.sub.i,x.sub.i), such that the i-th step has positive measure only if x.sub.i *A(v.sub.i,v.sub.i).noteq.0. Say that an L-process A is realizable if every chain of A admits of a realization. (5.1) Lemma: The following are equivalent for an L-process A: 1. A is realizable; 2. for each chain (v,x) of A and each i.gtoreq.0, x.sub.i *A(v.sub.i,v.sub.i)=0>x.sub.i+1,v.sub.i+1).noteq.0; 3. for each v, w V(A*), if x S.sub.A (v), x*A(v,v)=0 and x*A(v,w).noteq.0 then y*A(w,w).noteq.0 for all y S.sub.A (w).

Let A be an L-process. Define E.sup.1 (A)={e E(A).vertline.e.sup.- .noteq.e.sup.+ }, the set of non-self-loop edges of A. A set of states W V(A) is said to be stabilizing if each selection from each state w W enables the self-loop at w, i.e., x*A(w,.omega.).noteq.0 for each x S.sub.A (w), and for each e E.sup.1 (A), either e.sup.- W or e.sup.+ W or e.sup.+ W. If A admits of a stabilizing set of states, say A is stable.

(5.2) Theorem: An L-process is realizable if and only if it is stable.

For W V(A) define ##EQU21## A family of L-processes A.sub.1, . . . , A.sub.k is said to be a stable family if there are stabilizing sets of states W.sub.1, . . . , W.sub.k for A.sub.1, . . . , A.sub.k respectively such that for each i.noteq.j, 1.ltoreq.i,j.ltoreq.k,

p S.sub.A (W.sub.i), w W.sub.j >p*A.sub.j (w,w).noteq.0; (5.3) e E.sup.1 (A.sub.i), f E.sup.1 (A.sub.j), e.sup.- W.sub.i, f.sup.+ W.sub.j >A.sub.i (e)*A.sub.j (f)=0. (5.4) (5.5) Theorem: If A.sub.1, . . . , A.sub.k is a stable family of independent L-processes then A.sub.i is stable.

The previous two results give a general means for constructing realizable "systems" (processes whose product is realizable). Indeed, say an L-process A is a "memory" process if A is deterministic, and V(A) is stabilizing (then A in essence "selects its state" and holds the last value "assigned" to it). Say A is an "asynchonous controller" if some set of "pause" states V.sup.@ V(A) is stabilizing, if for some designated "pause" selection p, S.sub.A (v)={p} for all v V.sup.@ and if the L-matrix derived from M.sub.A by setting M.sub.A (v@,v@)=0 for each v@ V.sup.@ is deterministic (so A "pauses" for an indeterminant amount of time in state v@, selecting the "pause" selection p, thereafter non-deterministically moving to a uniquely designated non-pause state, say v, from which it may make an arbitrary selection and then either move to another "pause" state or self-loop). It is natural and convenient to build asynchronous systems from building blocks comprised of such "memory" processes and "asynchronous controllers". The latter can model delays across asynchronous interfaces, processing-time delays and indeterminacy of actions at higher levels of abstraction. It is likewise natural to model systems consistent with condition )5.3), as no process is expected to branch upon the "pause" (.ident."no information") selection of another process. Condition (5.4) is more problematic, in that it does not arise naturally. However, it does have a natural interpretation: among processes which stop "pausing" at the same time t, each of their respective subsequent "non-pause" selections must be in effect at time t (not one at t and the other in the open interval to the right of t). One way to enforce (5.4) is to choose some u L independent of the selections of all the processes in the system, and for each "asynchronous controller" process A, redefine M.sub.A (v@, v) to be u*M.sub.A (v@,v) for each v@ V.sup.@,v V.sup.@ and redefine M.sub.A (v,w@) to be .about.u*M.sub.A (v,w@) for w@ V.sup.@. This violates (4.10 ); however, the effect of this violation can be overlooked, since it does not alter the behavior of the component processes. It enforces the requirement that each process which changes its selection "at" time t has the new selection in effect at time t.

6. Verification

As stated in the introduction, "verification" is defined in terms of language properties. Specifically, let A be an L-process. A task for A is defined to be a set 2.sup.S(L).spsp..omega. of .omega.-languages over S(L). Say A performs the task provided (A) . This definition captures all possible notions of model-checking. For example, if represents the branching-time property that a certain state is reachable ("there exists a path from an initial state to the given state"), then consists of the set of all subsets of S(L).sup..omega. which contain at least one sequence admitting a run starting at an initial state and running through the given state. An important class of tasks is the class of .omega.-regular tasks: a task is .omega.-regular provided =2.sup. for some .omega.-regular language . Let =2.sup. be an .omega.-regular task for an L-process A. Then A performs iff (A) . Since is .omega.-regular, there is an L-automaton T such that = (T). In such a case we say "T is a task for A" and "A performs T" if (A) (T). For the remainder of the paper, all tasks are assumed to be .omega.-regular.

Let A be an L-automaton and let T be a deterministic L-automaton defining a task for A. Then task-performance (A) (T) may be decided in time linear in .vertline.M.sub.A M.sub.T .vertline.. .vertline.S(L).vertline.[Ku87]. As an arbitrary .omega.-regular language may be represented as ##EQU22## for deterministic L-automata T.sub.1, . . . , T.sub.n, (A) can be decided by deciding (A) (T.sub.i) for i=1, . . . , n. This is often appropriate in practice, as one often thinks in terms of separate deterministic tasks T.sub.1, . . . rather than .

Verification can sometimes be posed as a "controller synthesis" problem ]AKS83, RW87]: if (A) fails, it may nonetheless be the case that for some "controller" L-process C, (A) (C) , as (A) (C)= (A).andgate. (C). A necessary and sufficient condition for the existence of such a controller is that (C) (A).andgate. .orgate. (A)'.

In the course of defining and analyzing a system, one frequently places constraints or "commitments" on the "environment": the source of inputs to the system. Sometimes this has led to confusion due to the potential for circularity concerning "commitments" of the environment to the system and of the system to the environment: for example, "S works if E works; E works if S works" is satisfied if neither work. This potential for confusion can be avoided altogether by providing together with a model of the system, a model of the environment. Then, properties are proved about the closed system comprising the system-environment pair.

An important reduction method may be called "task decomposition". Suppose T is a task for A= A.sub.i which is "global" in the sense that each component A.sub.i "plays a part" in the performance of T. IN this case it may be conceptually difficult to see how to reduce the test (A) (T). For example, suppose A defines a communication protocol in its environment, as follows. A=S SP CH 1 CH 2 RP R where S and R model respectively the "sending" and "receiving" interfaces of the environment, CH 1 and CH 2 model respectively the outgoing and incoming channels between the sender and the receiver, and SP and RP model respectively the "sender protocol" and "receiver protocol" under development, to be verified. Suppose that the channels could lose messages, but the protocols SP and RP work on the basis of sending acknowledgements and retransmissions in case of failures. Let us say the task T is that every message sent by S in eventually received by R, unless there are continual channel failures. The validity of T must depend upon the entire global behavior of the "systems" modelled by A, as messages must flow from S to SP to CH 1 to RP to R, and in order to handle the case of a failure in CH 1, acknowledgements must flow from RP to CH 2 to SP. Therefore, it is unlikely that any significant abstraction of A relative to T could be forthcoming. Nonetheless, in general the task T may be "decomposed" into "subtasks" T.sub.1, . . . , T.sub.n such that ##EQU23## and (A) (T.sub.i) for each i=1, . . . , n, allowing for a reduction of each such test to a test (B.sub.i ') (T.sub.i '). In the example, T.sub.1 may be that the sent message arrives from S to SP; to prove this, we may take B.sub.1 '=S SP X where X is a significant abstraction of CH 1 CH 2 RP R. Likewise, T.sub.2, . . . may follow the flow of events related to the proper functioning of the protocol.

7. Homomorphism

Homomorphism, the basis of both reduction and refinement, is the means for dealing with large systems. Let L, L' be Boolean algebras, let .sigma.: S(L).fwdarw.S(L') be an arbitrary map and define the map

.PHI.:2.sup.S(L).spsp..omega. .fwdarw.2.sup.S(L').spsp..omega.(7.0.1) of the languages over L to the languages over L' by .PHI.( ={(.sigma.(x.sub.i)).sub.i .vertline.x }. Then .PHI. is said to be a (language) homomorphism with support .sigma.. If x S(L).sup..omega., define .PHI.(x)=(.sigma.(x.sub.i)).sub.i. It is shown in section 7.1 that the language homomorphism .PHI. gives rise to a Boolean algebra homomorphism F(.PHI.):L'.fwdarw.L, and conversely, for any Boolean algebra homomorphism .phi.:L'.fwdarw.L there is a unique language homomorphism (7.0.1) satisfying F(.PHI.)=.phi.. This relationship between a language homomorphism and a Boolean algebra homomorphism is used to generate a language homomorphism which guarantees (1.1) from conditions on the processes and automata. This duality relationship further provides the mechanism for the decomposition (1.2).

First, observe how a language homomorphism can be used to generate a reduction or refinement (1.1). Suppose A is an L-process, T is an L-automaton, A' is an L'-process and T' is an L'-automaton. We seek conditions on their respective languages which will guarantee that

(A') (T')> (A) (T). (7.0.2) Indeed, suppose a language homomorphism (7.0.1) satisfies .PHI. (A) (A'), (7.0.3) .PHI..sup.=1 (T') (T). (7.0.4) If (A') (T') then for any x (A), .PHI.(x) (A') so x .PHI..sup.-1 .PHI.(x) .PHI..sup.-1 (A') .PHI..sup.-1 (T') (T) and (7.0.2) follows.

7.1 Support

For the remainder of this paper it is assumed that all given Boolean algebras are complete (i.e., infinite products and sums exist [Ha74]). Suppose

.phi.:L'.fwdarw.L is a homomorphism of Boolean algebras. For each x L define x.sub..phi. =.pi.{y L'.vertline.x.ltoreq..phi.(y)}; since L' is complete, x.sub..phi. L'. The map .phi.:L.fwdarw.L' defined by .phi.(x)=x.sub..phi. is said to be the support of .phi.. (7.1.1) Proposition: For all x L, y L', x.ltoreq..phi.(x.sub..phi.), .phi.(y).sub..phi. .ltoreq.y. Proof: It follows from the Stone representation theorem [Ha74] that for x L, .phi.(x.sub..phi.)=.pi.{.phi.(y).vertline.y L', x.ltoreq..phi.(y)}.gtoreq.x. For y L', .phi.(y).sub.100 =.pi.{y' L'.vertline..phi.(y).ltoreq..phi.(y')}.ltoreq.y. (7.1.2) Lemma: x.sub..phi. =0 iff x=0. Proof: since 0.ltoreq..phi.(0) (=0), 0.sub..phi. =.pi.{y L'.vertline.0.ltoreq..phi.(y)}.ltoreq.0. Conversely, if x.sub..phi. =0 then by (7.1.1) x.ltoreq..phi.(x.sub..phi.)=.phi.(0)=0. (7.1.3) Proposition: x S(L)>x.sub..phi. S(L'). Proof: Say x.sub..phi. =y+z. Then by (7.1.1), x.ltoreq..phi.(x.sub..phi.)=y+z. since x S(L), we may suppose x.ltoreq..phi.(y); but then y+z=x.sub..phi. .ltoreq.y from the definition of x.sub.100, so z.ltoreq.y. By (7.1.2), x.sub..phi. .noteq.0, so it follows that x.sub..phi. S(L'). (7.1.4) Proposition: .phi.(x+x')=.phi.(x)+.phi.(x') for all x, x' L. Proof: since x.ltoreq..phi.(x.sub..phi.) and x'.ltoreq..phi.(x.sub..phi. '), x+x'.ltoreq..phi.(x.sub..phi.)+.phi.(x.sub..phi. ')=.phi.(x.sub..phi. +x.sub..phi. ') so by the definition of .phi., (x+x').sub..phi. .ltoreq.x.sub..phi. +x.sub..phi. '. Conversely, by (7.1.1), x.ltoreq.x+x'.ltoreq..phi.((x+x').sub..phi.) so again by the definition of .phi., x.sub..phi. .ltoreq.(x+x').sub..phi. ; similarly, x.sub..phi. '.ltoreq.(x+x').sub..phi. so x.sub..phi. +x.sub..phi. '.ltoreq.(x+x').sub..phi.. (7.1.5) Corollary: x.ltoreq.x'>x.sub..phi. .ltoreq.x.sub..phi. '. Proof: Set z=x'*.about.x. Then, by (7.1.4), x.sub..phi. .ltoreq.x.sub..phi. +z.sub..phi. =(x+z).sub..phi. =x.sub..phi. '. (7.1.6) Theorem: The following are equivalent: 1. .phi. is 1-1 (i.e., ker .phi.=0); 2. .phi. is onto; 2a. .phi.:S(L).fwdarw.S(L') is onto; 3. .phi.O.phi.=id (i.e., .phi.(y).sub..phi. =y for all y L'); 4. 1.sub..phi. =1. Proof: 1>3: Let z=.phi.(y).sub..phi.,z'=y*.about.z. Then z*z'=0 so since ker .phi.=0, .phi.(z)*.phi.(z')=0. By (7.1.1), .phi.(y).ltoreq..phi.(.phi.(y).sub..phi.)=.phi.(z) so .phi.(z)+.phi.(z') =.phi.(z+z')=.phi.(y+z)=.phi.(y)+.phi.(z)=.phi.(z) and thus .phi.(z')=0. Since ker .phi.=0 so y.ltoreq.z=.phi.(y).sub..phi.. But .phi.(y).sub..phi. .ltoreq.y by (7.1.1) so .phi.(y).sub..phi. =y. 3.fwdarw.2a: .phi.S(L) S(L') by (7.1.3); 3>.phi. is onto. 2a>2: L'= [S(L')]. 2>1: If .phi.(y)=0 then .phi.(x.sub..phi.)=0 for some x L (with x.sub..phi. =y) by 2., and x.ltoreq..phi.(x.sub..phi.)=0 so x=b 0. Thus, by (7.1.2) y=0. 4 2a: If 1.sub..phi. =1 then by (7.1.3) and (7.1.3), ##EQU24## so 2a. follows; if 2a. is true then 1=.SIGMA.s'=.SIGMA.s.sub..phi. =(.SIGMA.s).sub..phi. =1.sub..phi.. (7.1.7) Corollary: For all y L', ##EQU25## if .phi. is 1-1 then equality holds between the two sums. Proof: if x.sub..phi. .ltoreq.y then x.ltoreq..phi.(x.sub..phi.).ltoreq..phi.(y) so ##EQU26## On the other hand, .phi.(y).sub..phi. .ltoreq.y by (7.1.1) so substituting .phi.(y) for one of the summands x gives ##EQU27## and thus (8) holds. If .phi. is 1-1 then by (7.1.6) .phi. is onto; for each x L such that x.sub..phi. <y, let z=y*.about.x.sub..phi.. Since .phi. is onto there is some x' L such that x.sub..phi. '=z. Then, by (7.1.4), (x+x').sub..phi. =x.sub..phi. +x.sub..phi. '=y. It follows that (8) is an equality.

In the main result of this section, it is shown that the conditions of (7.1.3), (7.1.4) and (7.1.7) characterize the homomorphism .phi.. This will enable us to define .phi. form .phi..

Say that an arbitrary function f: L.fwdarw.L' is additively linear (respectively, monotone) if fx+y)=f(x)+f(y) (respectively, x.ltoreq.y>f(x).ltoreq.f(y)) for all x,y L. If f is additively linear, then, as in the proof of (7.1.5), f is monotone.

(7.1.8) Theorem: If f: L.fwdarw.L' is additively linear and f:S(L).fwdarw.S(L)') then the map .phi.:L'.fwdarw.L defined by ##EQU28## is a homomorphism and for all 0.noteq.x L', x.sub..phi. =f(x).

This theorem gives the functor F described at the beginning of section 7. Its importance lies in the fact that it shows that in order to generate the Boolean algebra homomorphism needed to define a language homomorphism satisfying (7.0.3) and (7.0.4), it is enough to define its support on the set of atoms S(L).

(7.1.9) Notes 1. Without the requirement that f:S(L).fwdarw.S(L'), it may happen that f is additively linear and yet the map ##EQU29## (x is not even additively linear (and thus not a homomorphism). Indeed, let L= [x,y], L'= [z] and define f:L.fwdarw.L' by f(x*y)=z, f(x*.about.y)=.about.z, f(.about.x*y)=f(.about.x*.about.y)=1 and extend this to L by linearity, with f(0)=0. then f is additively linear by construction, but .phi.(1)=1 whereas .phi.(z)+.phi.(.about.z)=x*y+x*.about.y=x<1.

2. In (7.1.8), if .vertline.fS(L).vertline.=1 (i.e., if f maps S(L) to a single atom of L') then the hom .phi. satisfies ##EQU30## However, it could happen that f(0)=f(1)>0. On the other hand, if .vertline.fS(L).vertline.>1, say s,t S(L) and f(s).noteq.f(t), then f(0)+f(s)=f(0+s)=f(s) so f(0).ltoreq.f(s) and likewise f(0).ltoreq.f(t), so (since f(s)*f(t)=0)f(0)=0.

(7.1.10) Lemma: f(x*x').ltoreq.f(x)*f(x'). Proof: since x*x'.ltoreq.x and x*x'.ltoreq.x', by the additivity of f, f is monotone and hence f(x*x').ltoreq.f(x), f(x*x').ltoreq.f(x') so f(x*x').ltoreq.f(x)*f(x'). (7.1.11) Note: ##EQU31## (7.1.12) Lemma: f.phi.(y).ltoreq.y,.phi.f(x).gtoreq.x. Proof: ##EQU32## Proof of (7.1.8): Let y.sub.1,y.sub.2 L'. Then f(.phi.(y.sub.1)+.phi.(y.sub.2))=f.phi.(y.sub.1)+f.phi.(y.sub.2).ltoreq.y.sub.1 +y.sub.2 by (7.1.12), so by (7.1.11) ##EQU33## If .phi.(y.sub.1)+.phi.(y.sub.2)<.phi.(y.sub.1 +y.sub.2) then there exists an atom t S(L) with t<.phi.(y.sub.1 +y.sub.2)*.about.(.phi.(y.sub.1)+.phi.(y.sub.1)+.phi.(y.sub.2)), and f(t) S(L'). But f.phi.(y.sub.1 +y.sub.2).ltoreq.y.sub.1 +y.sub.2 by (7.1.12) so by monotonicity f(t).ltoreq.f.phi.(y.sub.1 +y.sub.2).ltoreq.y.sub.1 +y.sub.2 ; since f(t) is an atom, we may as well assume f(t).ltoreq.y.sub.1. But then, by the definition of .phi.(y.sub.1), t.ltoreq..phi.(y.sub.1), a contradiction. Hence .phi. is additively linear. To show that .phi. is multiplicatively linear, observe that by (7.1.10) if f(x).ltoreq.y.sub.1 and f(x').ltoreq.y.sub.2 then f(x*x').ltoreq.f(x)*f(x').ltoreq.y.sub.1 *y.sub.2 while if f(x).ltoreq.y.sub.1 *y.sub.2 then x=x and f(x).ltoreq.y.sub.1, f(x).ltoreq.y.sub.2. Hence ##EQU34## Next, 1=f(1)+.about.f(1) so by (7.1.12) .phi.(1)=.phi.f(1)+.phi.(.about.f(1)).gtoreq.1+.phi.(.about.f(1))=1. Now, f:S(L).fwdarw.S(L') so by linear additivity of f, f(x)=0>x=0, so ##EQU35## and thus .phi.(.about.y).ltoreq..about..phi.(y). Also, 1=.phi.(1)=.phi.(.about.x+x)=.phi.(.about.y)+.phi.(y). Hence .about..phi.(y)=.about..phi.(y)*.phi.(.about.y)=.phi.(.about.y). It follows that .phi. is a homomorphism. Finally, for all x L, ##EQU36## On the other hand, if f(x)=0 then by (7.1.12) 0=.phi.f(x).gtoreq.x so x=0 and 0.sub..phi. =0=f(0). If f(x).noteq.0, write x=.SIGMA.s.sub.i where s.sub.i S(L). then f(x)=.SIGMA.f(S.sub.i) and f(s.sub.i) S(L') for all i. For any atom t.ltoreq.f(x) there exists an atom s each that s.ltoreq.x and f(s)=t. To show that f(x)=x.sub..phi. it suffices to show that t.ltoreq.x.sub..phi.. Indeed, if ##EQU37## then ##EQU38## so for some z, t.ltoreq.f(z).ltoreq.y. Thus, t.ltoreq.x.sub..phi. and it follows that f(x).ltoreq.x.sub..phi. so f(x)=x.sub..phi.. (7.1.13) Lemma: .phi.O.phi.=id on .phi. L and ker .phi.=(L' .phi.L).orgate.{0}. Proof: let x L. Then ##EQU39## by (7.1.7). Thus .phi.O.phi.(x.sub..phi.).gtoreq..phi.(.SIGMA.z)=.SIGMA.z.sub..phi. =x.sub..phi.. But .phi.O.phi.(x.sub..phi.).ltoreq.x.sub..phi. by (7.1.1). Therefore, .phi.O.phi.=id on .phi.L, and thus by (7.1.6) ker .phi..andgate..phi.L={0}. If y L' and .phi.(y).noteq.0 then s.ltoreq..phi.(y) for some atom s S(L), in which case s.sub..phi. .ltoreq..phi.(y).sub..phi. .ltoreq.y by (7.1.1), and so y L' .phi.L by (7.1.3). (7.1.14) Lemma: Suppose .phi., .psi.:L'.fwdarw.L are homomorphisms and .phi.=.psi. on S(L). Then .phi.=.psi.. Proof: if .phi.=.psi. on S(L) then by (7.1.4) and (7.1.2), .phi.=.psi. and ker .phi..psi. by (7.1.13). Therefore .phi.,.psi.:.phi.L.fwdarw.L have 0 kernel so by (7.1.6) for any y .phi.L, .psi.O.psi.(y)=y=.phi.O.phi.(y)=.psi.O.psi.(y), and .psi. is 1-1 on .phi.L. Therefore, .psi.(y)=.phi.(y) on .phi.L=.psi.L. Since by (7.1.13) ker .phi.=ker .psi.=(L' .psi.L).orgate.{0}, it follows that .phi.=.psi.. (7.1.15) Corollary: let .sigma.:S(L).fwdarw.S(L') be an arbitrary map. Then there exists a unique homomorphism .phi.:L'.fwdarw.L such that for all s S(L), s.sub..phi. =.sigma.(s). Proof: Define f:L.fwdarw.L' by extending .sigma. linearly to L: set f(0)=0 and for 0.noteq.x L, write x=.SIGMA.s.sub.i for s.sub.i S(L), and set f(x)=.SIGMA.f(s.sub.i). The result follows from (7.1.8) and (7.1.14). (7.1.16) Corollary: let .phi.:L'.fwdarw.L be a Boolean algebra homomorphism. Then there is a unique language homomorphism .PHI.:2.sup.S(L).spsp..omega. .fwdarw.2.sup.S(L').spsp..omega. with support .phi..

Suppose L.sub.1, . . . , L.sub.k are independent subalgebras of L with L=.pi.L.sub.i and L.sub.1 ', . . . , L.sub.k ' are independent subalgebras of L' with L'=.pi.L.sub.i '. If .sigma..sub.i :S(L.sub.i).fwdarw.S(L.sub.i ') are arbitrary maps for 1.ltoreq.i.ltoreq.k, we may define .sigma.:S(L).fwdarw.S(L') by .sigma.(s.sub.1 * . . . *s.sub.k)=.sigma..sub.1 (s.sub.1)* . . . *.sigma..sub.k), in which case by (7.1.15) there exists a unique homomorphism .phi.:L'.fwdarw.L with .phi.=.sigma. on S(L). Conversely, if .phi..sub.i :L.sub.i '.fwdarw.L.sub.i are arbitrary homomorphisms then .phi..sub.i :S(L.sub.i).fwdarw.S(L.sub.i ') and by (7.1.15) there is a unique homomorphism .phi.:L'.fwdarw.L with .phi.(s.sub.1 * . . . *s.sub.k)=.phi..sub.1 (s.sub.1)* . . . *.phi..sub.k (s.sub.k). Thus, we define the product homomorphism ##EQU40## It is this product which will allow us in the next sections to define a homomorphism of a product of L-automata or L-processes in terms of homomorphisms on the components.

7.2 L-Automaton Homomorphism

Let .GAMMA. be an L-automaton and let .GAMMA. be an L'-automaton. A homomorphism

.PHI.:.GAMMA..fwdarw..GAMMA.' is a pair of maps .phi.=(.phi.,.phi.') where .phi.:.GAMMA..fwdarw..GAMMA. is a graph homomorphism satisfying .phi..sup.-1 I(.GAMMA.') I(.GAMMA.) (7.2.1) .phi..sup.-1 R(.GAMMA.') R(.GAMMA.) (7.2.2) C' Z(.GAMMA.')>.phi..sup.-1 (C') C for some C Z(.GAMMA.) (7.2.3) and .phi.': L'.fwdarw.L is a Boolean algebra homomorphism such that for each (v,w) V(.GAMMA.).sup.2, .phi. and .phi.' jointly satisfy .GAMMA.(v,w).ltoreq..phi.'.GAMMA.'(.phi.(v), .phi.(w)). (7.2.4) If the containments in (7.2.1-3) are equalities and Z(.GAMMA.')={.PHI.(C).vertline.C Z(.GAMMA.)}, then .PHI. is said to be exact. We may denote .phi. and .phi.' by .PHI.. (7.1.5) Theorem: If .PHI.:.GAMMA..fwdarw..GAMMA.' is a homomorphism then ##EQU41## with equality holding when .GAMMA.' is deterministic. Proof: Inequality is clear. Suppose .SIGMA..GAMMA.(r,s)<.PHI..GAMMA.'(.PHI.(v),.PHI.(w)). then some atom t<.PHI..GAMMA.'(.PHI.(v), .PHI.(w)) satisfies t*.SIGMA..GAMMA.(r,s)=0. Let .PHI.(r.sub.0)=.phi.(v), .phi.(s.sub.0)=.phi.(w). Then t*.GAMMA.(r.sub.0,s.sub.0)=0, so for some s.sub.0 .noteq.s.sub.0, r*.GAMMA.(r.sub.0,s.sub.0).noteq.0, and .phi.(s.sub.0).noteq..phi.(w). Thus t*.phi..GAMMA.'(.PHI.(v), .PHI.(s.sub.0)).noteq.0 and hence 016 (.PHI..GAMMA.'(.PHI.(v), .PHI.(w)))*(.PHI..GAMMA.'(.PHI.(v), .phi.(s.sub.0)))=.PHI.(.GAMMA.'(.PHI.(v), .PHI.(w))*.GAMMA.'(.PHI.(v), .PHI.(s.sub.0))), contrary to the assumption that .GAMMA.' is deterministic. (7.2.6) Proposition: If .PHI.=(.phi.,.phi.') and .PSI.=(.psi.,.psi.') are homomorphisms, .PHI.:.GAMMA..fwdarw..GAMMA.' and .PSI.:.GAMMA.'.fwdarw..GAMMA.", then .PSI.O.PHI.=(.psi.O.phi.,.phi.'O.psi.') is a homomorphism .GAMMA..fwdarw..GAMMA."; if .PHI. and .PSI. are exact then so is .PSI.O.PHI.. (7.2.7) Lemma: let .PHI.:.GAMMA..fwdarw..GAMMA.' be a homomorphism. If .GAMMA.' is deterministic then .PHI.:E(.GAMMA.).fwdarw.E(.GAMMA.') is onto. Proof: Let v V(.GAMMA.'). Then there is a path (v.sub.0, . . . ,v.sub.n) in .GAMMA.' with v.sub.0 I(.GAMMA.') and v.sub.n =v. The proof that .PHI. is onto follows by induction on n. If n=0, then v.sub.0 .PHI.V(.GAMMA.) by the definition of .PHI.. If v.sub.0, . . . , v.sub.n=1 .PHI.V(.GAMMA.), let v.sub.n-1 .PHI..sup.-1 (v.sub.n-1) and let w.sub.1, . . . , w.sub.m be exactly those states of .GAMMA. satisfying .GAMMA.(V.sub.n-1, w.sub.i).noteq.0. Then ##EQU42## Since .GAMMA.' is deterministic and .GAMMA.'(v.sub.n-1,v.sub.n).noteq.0, v.sub.n =.PHI.(w.sub.i) for some i, completing the induction step. The same proof thus shows that .PHI.:E(.GAMMA.).fwdarw.E(.GAMMA.') in onto. Let .GAMMA. be an L-automaton, let .GAMMA.' be an L'-automaton and let .PHI.:.GAMMA..fwdarw..GAMMA.' be an exact homomorphism. An L' automaton .PHI.(.GAMMA.), the image of .GAMMA. under .PHI., is defined in terms of S(L') as follows: ##EQU43## (where .PHI. is the support of the Boolean algebra homomorphism .PHI.:L'.fwdarw.L), I(.PHI.(.GAMMA.))=.PHI.I(.GAMMA.), R(.PHI.(.GAMMA.))=.PHI.R(.GAMMA.), Z(.PHI.(.GAMMA.))=.PHI.Z(.GAMMA.) (where .PHI.z(.GAMMA.)={.PHI.(C).vertline.C Z(.GAMMA.)}. (7.2.8) Lemma: .PHI.(.GAMMA.) is an L'-automaton, and .PHI.:.GAMMA..fwdarw..PHI.(.GAMMA.) maps E(.GAMMA.).fwdarw.E(.PHI..GAMMA.) onto. Proof: It must be checked that .PHI.(.GAMMA.) is complete. Suppose for some v V(.GAMMA.), t S(L') and ##EQU44## Then, by (7.2.4) ##EQU45## contradicting the fact that .GAMMA. is complete. To check that .PHI.:E(.GAMMA.).fwdarw.E(.PHI..GAMMA.) is onto, suppose e E(.PHI..GAMMA.) and let t be an atom of L' such that t*(.PHI..GAMMA.)(e).noteq.0. Then for some v,w V(.GAMMA.) with (.PHI.v, .PHI.w)=e, .GAMMA.(v,w)*.PHI.(t).noteq.0, proving that (v,w) E(.GAMMA.). Note: It is possible for .GAMMA. to be deterministic while .PHI..GAMMA. is not deterministic, as well as for .PHI..GAMMA. to be deterministic while .GAMMA. is not deterministic. (7.2.9) Corollary: If .PHI.:.GAMMA..fwdarw..GAMMA.' and .GAMMA.' is deterministic, then .PHI.(.GAMMA.)=.GAMMA.'. Proof: Let t be an atom satisfying t*.GAMMA.'(.PHI.(v), .PHI.(w)).noteq.0. For some u V(.GAMMA.), .GAMMA.(v,u)*.PHI.(t).noteq.0. Then 0.noteq..GAMMA.(v,u)*.PHI.(t).ltoreq..PHI.(.PHI..GAMMA.)(.PHI.v, .PHI.u)*.PHI.(t), so 0.noteq.(.PHI..GAMMA.)(.PHI.v, .PHI.u)*t. By the determinism of .GAMMA.', .PHI.u=.PHI.w. Thus, .PHI.(.GAMMA.)(.PHI.(v), .PHI.(w))=.GAMMA.'(.PHI.(v), .PHI.(w)). the conclusion follows. If .PHI.:.GAMMA..fwdarw..GAMMA.' is a homomorphism of the L-automaton .GAMMA. to the L'-automaton .GAMMA.', then the support .PHI. of the Boolean algebra homomorphism .PHI.:L'.fwdarw.L induces a language homomorphism (7.0.1) which it is natural to call .PHI., as well. (7.2.10) Theorem: If .GAMMA. is an L-automaton, .GAMMA.' is an L'-automaton and .PHI.:.GAMMA..fwdarw..GAMMA.' is a homomorphism, then .PHI..sup.-1 (.GAMMA.') (.GAMMA.), with equality holding if .PHI. is exact. Proof: Let c'=(v',x') be a chain of .GAMMA.', and let .PHI..sup.-1 (c')={c=(v,x).vertline..PHI.(c)=c'} where .PHI.(c)=((.PHI.(v.sub.i)).sub.i, (.PHI.(x.sub.i)).sub.i). By (7.1.3) and (7.2.1-4) it follows that .PHI..sup.-1 (c') (.GAMMA.). Now, x (.GAMMA.) iff (x,v) (.GAMMA.) for some v, so .PHI..sup.-1 (.GAMMA.') (.GAMMA.). If .PHI. is exact, then .PHI. (.GAMMA.) (.GAMMA.') and thus .PHI. (.GAMMA.)= (.GAMMA.'), so (.GAMMA.)=.PHI..sup.-1 (.GAMMA.'). (7.2.11) Corollary: If .PHI.:.GAMMA..fwdarw..GAMMA.' is a homomorphism then (.GAMMA.') .PHI. (.GAMMA.); if .PHI. is exact, (.GAMMA.')=.PHI. (.GAMMA.). Let .LAMBDA.,.GAMMA. be L-atuomata and let .LAMBDA.', .GAMMA.' be L'-automata. Homomorphisms .PHI.:.LAMBDA..fwdarw..LAMBDA.' and .PSI.:.GAMMA..fwdarw..GAMMA.' are said to be co-linear if they agree on L', i.e. .PHI.=.PSI.:L'.fwdarw.L. (7.2.12) Corollary: Let .PHI.:.LAMBDA..fwdarw..LAMBDA.' and .PSI.:.GAMMA..fwdarw..GAMMA.' be co-linear homomorphisms. Then 1. if .PHI. is exact then (.LAMBDA.') (.GAMMA.')> (.LAMBDA.) (.GAMMA.); 2. if .PSI. is exact then (.LAMBDA.) (.GAMMA.)> (.LAMBDA.') (.GAMMA.'). Proof: If .PHI. is exact and (.LAMBDA.') (.GAMMA.') then (.LAMBDA.)=.PHI..sup.-1 (.LAMBDA.') .PHI..sup.-1 (.GAMMA.')=.PSI..sup.-1 (.GAMMA.') (.GAMMA.). If .PSI. is exact and (.LAMBDA.) (.GAMMA.) then .PHI..sup.-1 (.LAMBDA.') (.LAMBDA.) (.GAMMA.) so (.LAMBDA.') .PHI. (.GAMMA.)=.PSI. (.GAMMA.)= (.GAMMA.').

7.3 L-Process Homomorphism

Process homomorphism is defined in a manner strictly analogous to automaton homomorphism, yielding analogous results. However, because of the difference in acceptance (the cyclic and recurring conditions for automata are negations of the respective conditions (4.3-4) for processes), and on account of the selections in processes, it is necessary to clarify the details.

Let .GAMMA. be an L-process and let .GAMMA.' be an L'-process. A homomorphism

.PHI..GAMMA..fwdarw..GAMMA.' is a pair of maps .PHI.=(.PHI.,.psi.') as in the definition of automaton homomorphism, satisfying (7.2.1-4). We adopt the same terminology and notational conventions here.

Let A be a lockup-free L-process, A' an L'-process and .PHI.:A.fwdarw.A' a homomorphism. It follows from (4.2), (7.1.13) and the homomorphism condition (7.2.4) that for each x S.sub.A (v) there exists an x' S.sub.A' (.PHI.v) such that .PHI.(x).ltoreq.x'. Thus, if A.sub.1, . . . , A.sub.k are a family of independent, lockup-free L-processes with L= [S(A)] for A= A.sub.i, then in view of section (7.1), any homomorphism of A is uniquely defined in terms of maps of the selections of A.sub.1, . . . , A.sub.k. Thus, homomorphisms of A are determined by homomorphisms of A.sub.1, . . . , A.sub.k.

It is easily checked that the corresponding results to (7.2.5-9) hold for L-processes. Analogously, the following hold.

Theorem: If A is an L-process, A' is an L'-process and .PHI.:A.fwdarw.A' is a homomorphism then .PHI. (A) (A'), with equality holding if .PHI. is exact. Theorem: Let A be an L-process, T an L-automaton, A' an L'-process, T' an L'-automaton and suppose .PHI.:A.fwdarw.A' .PSI.:T.fwdarw.T' are co-linear homomorphisms. Then 1. (A') (T')> (A) (T); 2. if .PHI. and .PSI. are exact, (A) (T)> (A') (T').

8. Conclusions

Homomorphism has been shown to be a tool for reduction and refinement. It was shown how a homomorphism can be defined on a large space (implicitly) through homomorphisms on components. In the development of software and hardware systems, one begins with an abstract, high-level design and formally verifies that design for the performance of a variety of tasks, using reductions to cope with the complexity of this verification. Next, one redefines this design, adding more details. It is verified that this more detailed design is a refinement of the original design, and hence that all tasks whose performance were verified for the high-level design are guaranteed to be performed by the more detailed design as well. This is equivalent to proving that the high-level design is a reduction of the more detailed design, relative to all tasks performed by the high-level design (pulled back to the more detailed design). The more detailed design is verified for the performance of tasks not definable at the high level.

This step-wise refinement and verification continues until all details of the final implementation have been added to the model.

A measure of the success of this methodology may be taken from its application to large system development [HK90], where an order of magnitude saving in development time has been demonstrated, together with the production of an implementation which passing system test on the first trial with zero errors (virtually unknown with conventional development).

REFERENCES

[RS59] M. O. Rabin, D. Scott, "Finite Automata and their Decisions Problems", IBM J. Res. and Dev. 3(1959) 114-125. (Reprinted in [Mo64] 63-91.) [Ts59] M. L. Tsetlin, "Non-primitive Circuits" (in Russian) Problemy Kibernetiki 2 (1959). [Bu62] J. R. Buchi, "On a Decision Method in Restricted Second-Order Arithmetic", Proc. Internat. Cong. on Logic, Methodol. and Philos. of Sci., 1960, 1-11 (Stanford Univ. Press, 1962). [Ra69] M. O. Rabin, "Decidability of Second-Order Theories and Automata on Infinite Trees", Trans. Amer. Math. Soc. 141 (1969) 1-35. [Ra72] M. O. Rabin, Automata on Infinite Objects and Church's Problem. Amer. Math. Soc., 1972. [Ch74] Y. Choueks, "Theories of Automata on .omega.-Tapes: A Simplified Approach", J. Comput. Syst. Sci. 8 (1974), 117-141. Ha74] P. Halmos, Lectures on Boolean Algebras, Springer-Verlag, N.Y., 1974. [GK80] B. Gopinath, R. P. Kurshan, "The Selection/Resolution Model of Coordinating Concurrent Processes", internal AT&T report. [AKS83] S. Aggarwal, R. P. Kurshan. K. K. Sabnari, "A Calculus for Protocol Specification and Validation" in Protocol Specification, Testing and Verification, III, North-Holland, 1983, 19-34. [DC85] D. L. Dill, E. M. Clarke, "Automatic Verification of Asynchronous Circuits Using Temporal Logic", Proc. Chapel Hill Conf. VLSI, Computer Sci. Press (1985) 127-143. [Ku85] R. P. Kurshan, "Modelling Concurrent Processes", Proc. Symp. Applied Math, 3 (1985) 45-57. [SVW85] A. P. Sistla, M. Y. Vardi, P. Wolper, "The Complementation Problem for Buchi Automata, with Applications to Temporal Logic", in Proc. 12th Internat. Coll. on Automata, Languages and Programming, Lect. Notes Comp. Sci., 1985, Springer-Verlag. [WA85] W. W. Wadge, E. A. Ashcroft, LUCID, The Dataflow Programming Language, Academic Press, 1985. [KK86] J. Katzenelson and R. P. Kurshan, "S/R: A Language For Specifying Protocols and Other Coordinating Processes", Proc. 5th Ann. Int'l Phoenix Conf. Comput. Commun., IEEE, 1986, 286-292. [BC87] M. C. Brown, E. M. Clarke, "SML--A High Level Language for the Design and Verification of Finite State Machines", in from HDL Descriptions to Guaranteed Correct Circuit Designs (D.Borrione, ed.) North-Holland (1987) 269-292. [GK87] I. Gertner, R. P. Kurshan, "Logical Analysis of Digital Circuits", Proc. 8th Intn'l. Conf. Comput. Hardware Description Languages, 1987, 47-67. [Ku87] R. P. Kurshan, "Reducibility in Analysis of Coordination", LNCIS 103 (1987) Springer Verlag, 19-39. [Ku87a] R. P. Kurshan, "Complementing Deterministic Buchi Automata in Polynomial Time", J. Comput. Syst. Sci. 35(1987)59-71. [RW87] P. J. Ramadge, W. M. Wonham, "Supervisory Control of a Class of Discrete-Event Processes", SIAM J. Contr. Opt. 25(1987) 206-230. [Sa88] S. Safra, "On the Complexity of .omega.-Automata", 29.sup.th FOCS (1988) 319-327. [Ba89] J. Barwise, "Mathematical Proofs of Computer System Correctness", Notices AMS 36(1989) 884-851. [KM89] R. P. Kurshan, K. McMillan, "A Structural Induction Theorem for Processes", Proc. 8th ACM Symp. PODC (1989) 239-247. [KM90] R. P. Kurshan, K. McMillan, "Analysis of Digital Circuits Through Symbolic Reduction", IEEE Trans. CAD/ICS, to appear. [HK90] Z. Har'El, R. P. Kurshan, "Software for analytical Development of Communication Protocols", AT&T Tech. J., to appear.

SUMMARY

0. The S/R Model.

1. The Graph Generator: This section explains the method for cranking a next state, including the `odometers` for selections and resolutions. We must also explain here how pause states are represented, how they are resolved, and how certain resolutions are prevented to ensure proper real time behavior of the system (i.e., "normalization". This is done using the `crank counters` c1 and c2).

2. The Search: In this section the reached state boundary stack and the ancestor stacks are explained, as well as their implementation. It illustrates the combination of the inherent BFS nature if the s/r machine with the DES needed for cycle recognition.

3. The Acceptance Test: This section explained how a simple cycle recognition is replaced by the Tarjan's strongly connected component algorithm, which is essentially lowlink computations superimposed on the same backtrack mechanism of the DFS. Cysets may be explained here. The second acceptance device, the recur edges, is explained, and also the mechanism of pushing `recur vertices` at the bottom of the stack, which makes it practically into a queue. The reasons for implementing it as a circular queue are explained(?).

4. The Transition Checks: This section explains lockups, nondeterminism, deadlocks and stability failures. It also explains how semi-determinism may be used to simplify graph generation.

5. Merge and Reduce

6. Simulation: This section explains the usage of simulation for testing: Non robust protocols which work for given hold times only, or protocols which are too large to be handled by exhaustive searches. One does the testing by simulation runs, without any memory or with a fixed queue of last k states for debugging purposes. One may check for star free regular expressions, i.e., avoiding "bad sequences". We also explains how simulation is used to compute means first passage time between a given state to a set of ending states.

2. The Search.

In this section, we describe the search algorithm on the coordination graph. This can be viewed as a subgraph G*=(V*,E*) of a general directed graph G=(V,E) which is reachable from a given subset I of initial vertices. We note that the graph is not known at the beginning of the search. What we are given is rather a graph generator, i.e. a procedure which generates the children of a given parent vertex, thus making a "breadth first search" the natural thing to do on such a graph. However, for various applications such as checking acyclicity, we need a depth-first spanning forest for (V*,E*). We wish to describe an algorithm for finding such a forest and for counting the edges of E* classified by depth first categories: Tree edges, forward edges, self edges, back edges and cross edges. G* is acyclic if and only if there are no self edges and no back edges. Thus, we introduce a search which starts at an initial vertex, cranks all its children and records them in a Reached State Table. We call such a recorded vertex reached, and a vertex whose all children have been recorded will be called searched. The next vertex to be searched is one of the children of the initial vertex, and then we search a grandchild, and so forth as deep as possible, in a depth-first fashion. The order in which the vertices are being searched induces a depth first forest with roots at certain initial vertices. If we delete a subset P of edges of G, the same procedure will give us a depth first forest for (V*, E*-P). In the extreme case that all the edges are deleted, the forest will degenerate into a set of roots, and the order in which they are searched will realize a breadth-first search on (V*,E*-P).

As we said above, each reached vertex is recorded in the RST. With each v in V* we associate a pointer to its record, name(v )=v is only one of the fields in this record. Other fields which are used in the search are parent(v ), which is initially empty, and ultimately contains a pointer to the parent of v in the induced depth-first forest, and origin(v ), which contains a pointer to the most recent parent of v, and enables avoiding duplications in counting edges between the same pair of vertices. The RST record also contains two flags, permanent(v ), which is set for vertices which have been searched, and inpath(v ), which is set if v (in case v is permanent) or one of its ancestors (otherwise) is in the current depth first search path. More fields will be introduced in the next section, as they are required for the implementation of Tarjan's strong connectivity algorithm. Finally, two fields are required for maintaining the data structure itself (and thus, are transparent to the algorithm below): A pointer Hash(v ), for the next record in the RST, such that name(hash(v )) is a vertex which "collides" with v in the open hashing scheme, and an integer index(v ), which is the ordinal number of v in the order of reachability, which is necessary as the RST is not contiguous in memory but rather allocated a chunk at a time. Once the search is done, the RST may be saved as an array, with all the pointers (which are implemented as memory addresses) replaced by the corresponding indices. The saved RST contains a depth first forest of (V*,E*-P) and the strong connectivity decomposition which we describe in the next section.

A second data structure used in the search is the Boundary Deque. This is a linear list, a little more restrictive than Knuth's deque. We call one end of the list its top, and the other the rear, and we allow both stack (LIFO) and queue (FIFO) operations: Data is always taken (accessed and deleted) from the top, but is put (inserted) either at the top, as in a stack, or at the rear, as in a queue. The BD is used to save the pointers to the children of each searched vertex, until it is time to search them. Pointers to end-vertices of deleted edges are put at the rear, and thus are not searched until every body else has been searched, while other are inserted at the top. Thus, in the extreme case P is empty, BD is a pure stack, while in the other extremity, P=E, BD is a pure queue.

We now describe the algorithm itself.

Definition: A graph generator is an ordered pair (V,c) of a finite set V, called the set of vertices, and a function c from V to its power set, called the child-set function. The graph generated by (V,c) is G=(V,E), where E is the subset of V.times.V consisting of all pairs (v,w) such w is a member of c(v).

Definition: Let G=(V,E) be a graph, and I is a subset of V, called the initial set. The reachable subgraph of (G,I) is the graph G*=(V*,E*), where V* is the subset of V consisting of the vertices v such that either v is in I or there exist a finite path (w, . . . , v) in G such that w is in I, and E* is the intersection of V*.times.V* with E.

Algorithm A: (1) back:=0 (no backtrack necessary). (2) Take an initial vertex v from I. If no more, go to (6). (3) Record v in RST. (4) parent(v );=empty, origin(v );=empty, permanent(v );=0, inpath(v (;=0. (5) Put v at rear (or top) of BD. Go to (2). (6) Take a v from top of BD. If empty, stop (search done). (7) If permanent(v )=1 (v has already been searched), go to (6). (8) If back=0, go to (13) (no backtrack). (9) (backtrack the search path) If inpath(v )=1 and parent(v ).noteq.empty, then top:=parent(v ) (top points to the vertex to which we have to backtrack). Otherwise, top:=empty (backtrack the whole path). (10) w :=connect (connect points to the vertex where the backtrack begins, i.e., the point where we couldn't search any deeper). (11) inpath(w ):=0 (remove w from the path). w :=parent(w ) (backtrack one edge). If w =empty, go to (13). (12) If w .noteq.top, go to (11). (13) (backtrack complete) permanent(v ):=1. inpath(v ):=1 (add v to the search path). (14) connect:=v , back:=1 (we save our position in connect in case back is not eventually cleared and we must backtrack). *(15) If parent(v )=empty (v is a root in the depth-first tree), increment #root. Otherwise, increment #tree, decrement #forward (parent.fwdarw.v is a tree edge but has been counted as a forward edge in step (22)). (16) Take a child vertex w from c(v). If no more, go to (6). (17) Record w in RST. If already there, new:=0; otherwise, new:=1. (18) If new=1, then parent (w ):=empty, origin(w ):=empty, permanent(w ):=0, inpath(w ):=0. *(19) If origin(w )=v (w has already been reached as a child of v), then increment #ignore (v.fwdarw.w is duplicate), go to (16); otherwise, origin(w ):=v . (20) If permanent (w )=1, go to (24 ). (21) (w has not been searched yet) If v.fwdarw.w is in P, go to (23). *(22) (It is too early to decide if v.fwdarw.w is a forward edge or a tree edge) Insert w at the top of BD. parent(w ):=v : inpath(w )=1 (w has a parent in the path), back:=0 (as v has a non-searched child, do not backtrack). Increment #forward. Go to (16). *(23) (v.fwdarw.w is a deleted edge) If new=1, put w at rear of BD (if w is not new, it is already in BD, and we don't mind where). Increment #plus. Go to (16). *(24) (w has already been searched) If v.fwdarw.w is in P, increment #plus, go to (16). *(25) If w =v (v.fwdarw.w is a self edge), increment #self, go to (16). *(26) (v.fwdarw.w is a back edge or a cross edge) If inpath(w )=1 (w is an ancestor of v in the path), increment #back; otherwise, increment #cross. Go to (16).

Note: If no edge accounting is necessary, the updating of the counters #. . . in the starred steps may be omitted. The tests in steps (24)-(26) are still required for an acyclicity check. The test in step (19) together with the RST field origin may be omitted at the expense of the extra time involved in searching duplicate edges.

Theorem A: Given a graph generator (V,c), an initial subset I of V,a deleted subset P of V.times.V, algorithm A produces a depth first forest for (V*,E*).

The fact that algorithm A realizes a depth first search is standard, the parent and inpath RST fields implement a stack which replaces the usual recursiveness. The back flag, connect and top pointers tell us whether we should backtrack, from where an to where, respectively.

3. The Acceptance Test.

We now add more structure to G. In addition to the initial set of vertices I, the deleted set of edges P, we are now given a family of sets of vertices C={C1,C2,C3, . . . , Cn). In section 2, we could test of G* had any cycle at all, we are now in position to ask if the vertices of each cycle in G* (if any) are contained in some Ci. For that end, we adapt our search so it will decompose G* into strongly connected components. Each component, unless it is degenerate to a single vertex with no self edge at it, is tested for containment in a member of C. Following Tarjan, we add some more fields to the RST: The integers dfnumber(v ) and lowlink(v ) are respectively the ordinal number of v in the induced depth first search, and Tarjan's index defining the least ordinal, dfnumber(w ), of a vertex w belonging to the same component and reachable from v by a path consisting of tree edges followed by at most one back edge or one cross edge. In the modified algorithm, we can also distinguish between intercomponent and intracomponent cross edges as a by product from the lowlink calculation. Finally, Tarjan's stack of points is implemented by adding a third pointer field to the RST, denoted connect(v ), which links the entry for v with the entry for the previously found vertex in the same component, and a flag inscc(v ), which is set if v is in the current component, and cleared to simulate deleting v from the stack of points. Two more flags, root(v ) and self(v ), are set respectively if v is the root of the depth-first subtree of its strongly-connected component, and if v has a self-edge. The former is used to delimit the components in the connect list--the list of RST entries linked together by the connect field, and the latter is used to determine degeneracy of singleton components.

We now present the Strong connectivity algorithm. Since it is a modification of the algorithm in section 2, we omit the unmodified steps. We note, however, that while the original search is over at the moment the BD is empty, we still have to look for components in the last path.

Algorithm B: (1) . . . (1') count:=-1. last:=empty. (. . . ) . . . (4) . . . (4') inscc(v ):=0. connect(v ):=empty. (5) . . . (6) Take a v from top of BD. If empty, then v :=empty, go to (8). (7) . . . (8) . . . (8') root:=empty (rootwill point to the root of the subtree of the current component). If v =empty, then top:=empty, go to (10); (. . . ) . . . (11) inpath(w ):=0. If lowlink=dfnumber(w ) (w is a root of the current component subtree), then root:=w , root(w ):=1. w :=parent(w ). If w =empty go to (13). (11') If lowlink(w )>lowlink, lowlink(w :=lowlink; Otherwise, lowlink:=lowlink(w ). (12) . . . (13) (backtrack complete) if root.noteq.empty (found at least one complete component), check the connect list from connect to root for containment at a Ci (see Note below). w :=connect. connect:=connect(root). connect(root:=last:=w . (last points to the vertex where the backtrack started, and it is the new beginning for the connect list. Its new end is linked to the previous beginning.) (13') If v =empty, stop (search complete). permanent(v ):=1. inpath(v ):=1. inscc(v ):=1. Increment count. dfnumber(v ):=count. lowlink:=count. connect(v ):=connect. (. . . ) . . . (16) Take a child vertex w from c(v). If no more, then lowlink(v ):=lowlink, go to (6). (. . . ) . . . (26) (v.fwdarw.w is a back edge or cross edge) If inscc(w )=1 and lowlink>dfnumber(w ), lowlink:=dfnumber(w ) (update lowlink to be the minimum dfnumber for all end vertices of back edges or cross edges starting at v and ending in the same component). (26') If inpath(w )=1, increment #back. Otherwise, if inscc(w )=1, increment #intra (an intracomponent cross edge). Otherwise, increment #inter (an intercomponent cross edge). Go to (16).

Note: In step (13) above, a check the connect list is called for. The only action relevant to the decomposition algorithm proper is the clearing of the inscc flag for all the entries in the list. We shall not elaborate the strongly connected component checking algorithm here, except for mentioning that it uses the root and self flags in the RST, in their significance mentioned above.

Theorem B: Given a graph generator (V,c), an initial subset I of V, a deleted subset P of V.times.V, algorithm B produces a decomposition of (V*,E*-P) into strongly connected components. The theorem follows if one verifies that the lowlink calculations, done recursively in Tarjan's original algorithm, may be done during the search backtrack steps and the classification of out edges, as above.

4. The Transition Checks.

In analyzing coordination, we do several checks on the validity of state transitions. This is done in several levels: When cranking next states, we first check for lockups, which are actually deficiencies in the specification of coordinating processes: In a particular state, we cannot compute some of the components of the global selection, or otherwise we cannot compute some resolutions. We than check for various degrees of determinism. A system of processes will be deterministic if there is only one selection for a process in each given state. A non-deterministic system can still have semi deterministic resolutions (or simply, the system is semi-deterministic), that is have only one resolution for each global selection in a given state. In checking semi-determinism, we also allow any component process to stop pausing non-deterministically, counting the two possibilities as a single resolution.

As we have mentioned, lockups and determinism are checked during graph generation. During the actual search, we first check for deadlocks. These are vertices of G* with no children except possibly the vertex itself, i.e., with no out-edges except the self-edge. This check is done by setting a flag when searching a new state (step (14)), and clearing it when traversing any non-self out edge. The last transition check is the stability check, which we now explain.

When one considers the real time behavior of a semi-deterministic system, one can distinguish between two types of state transitions, and in accordance also two types of states. A critical transition v.fwdarw.w is one where v and w are nominally distinct. Such a transition is considered to occur instantaneously. In contrast, A noncritical transition will involve just one or more processes stop pausing, and thus will have a non-deterministic positive duration. Noncritical states are states in which the system can pause for a positive period of time, due to the property that any transition from such a state are noncritical. Any other state is said to be critical, and in such a state it is possible to make a global selection which will resolve in a critical transition. An semideterministic system is said to be stable if it never has two consecutive critical transitions, or, equivalently, there is no edge v.fwdarw.w in the coordination graph G* such that both v and w are critical. To classify the vertices in V* and to detect stability failure, the following variation of the basic search algorithm is used:

Algorithm C: (1) . . . (1') stable:=1. (. . . ) . . . (15) . . . (15') move:=0. (16) Take a child vertex w from c(v). If no more, then move(v ):=move, go to (6). If v.fwdarw.w is critical, c2:=1; otherwise, c2:=0. (. . . ) . . . (19) . . . (19') If c2=0, go to (20). move:=1. If permanent(w )=0, move(w ):=1. (19") If stable=0 go to (20) (stability failed before, don't check again). If permanent(w )=1 and move(w )=1 and move(w )=1, then stable:=0; otherwise, if move(v )=1, stable:=1. (. . . ) . . .

Theorem C:Algorithm C produces a decomposition of V* into critical and non-critical states and tests the stability of G*.

When the search is over, for each v in V*, the RST flag move(v ) will be set if and only if v is critical. Also, the flag stable will be set if and only if G* is stable. To see that, we first observe that by (19'), until w is searched, move(w ) is set if and only if it has a parent v such that v.fwdarw.w is critical. On the other hand, once v is has been searched, move(v ) is set in (16) if and only if move has been ever set in (19'), i.e., if and only if it has a child w such that v.fwdarw.w is critical. Thus, the first part of Theorem C follows. To prove the other part, consider any stability failure caused by two consecutive critical edges in G*, let v.fwdarw.w be the second of these edges in the induced depth first search. Consider the following two alternatives for the critical transition v.fwdarw.w to fail stability: Either w is known to have a critical out-edge, or v is known to have a critical in-edge. The former alternative is equivalent to w having been already searched (otherwise its out-edges are not known) and being critical. The latter is equivalent to v having a parent u such that u.fwdarw.v is critical. Thus above observation, we must have either move(w =1 (and w permanent) or move(v )=1, as in step (19").

Claims

1. In a computer, a method for creating a sequential circuit comprising the steps of:

receiving a specification and tasks for said sequential circuit;

testing whether said tasks are performable in said sequential circuit when said circuit conforms to said specification;

forming a refined specification by adding detailed information about said specification and defining new tasks to be performed;

formally verifying that said refined specification preserves behavior of said given specification, in that the response of said circuit to input signals when it conforms to said refined specification is consonant with the response of said circuit to the same input signals when it conforms to said given specification;

replacing said tasks with said new tasks and said specification with said refined specification, and returning to said step of testing; and

developing and delivering structure information based on said specification, for effectuating said sequential circuit.

2. The method of claim 1 wherein said step of testing includes testing to determine whether to cease forming a refined specification.

3. In a computer a method for creating a sequential circuit that performs given tasks, comprising the steps of:

entering into an analyzer a specification of said sequential circuit;

forming a refined specification by adding to said analyzer detailed information absent in said specification;

formally verifying that said refined specification preserves behavior of said specification, in that the response of said circuit to input signals when it conforms to said refined specification is consonant with the response of said circuit to the same input signals when it conforms to said specification;

replacing said specification with said refined specification, and returning to said step of forming; and

developing and delivering out of said analyzer structure information based on said specification, for effectuating said sequential circuit.

4. The method of claim 3 further comprising a step of incorporating said structure information in a pattern of connections of an integrated circuit.

5. The method of claim 3 further comprising a step of incorporating said structure information in a layout of an integrated circuit.

6. The method of claim 3 wherein said structure information comprises a sequence of control signals for controlling a processor to effectuate said sequential circuit.

7. The method of claim 6 wherein said control signals are adapted for controlling a stored program processor.

8. The method of claim 7 wherein said control signals form a plurality of modules and each module forms a switch statement construct with reference to no other modules except for modules that control input and output functions of said stored program processor.

9. In a computer, a method for creating a sequential circuit that performs given tasks in accordance with a given specification, comprising the steps of:

defining a reduction of said given specification for each of said given tasks to form a reduced specification for each task;

testing that each reduced specification subsumes said given specification with respect to said task and leaves its corresponding task invariant;

testing each task to determine that it is performable in a circuit that conforms to the reduced specification corresponding to the tested task;

developing circuit structure information, based on said given specification, for effectuating said sequential circuit; and incorporating said structure information in a pattern of connections of an integrated circuit.

10. The method of claim 9 further comprising a step of incorporating said structure information in a layout of an integrated circuit.

11. The method of claim 9 wherein said structure information comprises a sequence of control signals based on said given specification, for controlling a processor to effectuate said sequential circuit.

12. The method of claim 11 wherein said control signals are adapted for controlling a stored program processor.

13. The method of claim 12 wherein said control signals form a plurality of modules and each module forms a switch statement construct with reference to no other modules except for modules that control input and output functions of said stored program processor.

14. In a computer, a method for creating a sequential circuit comprising the steps of:

entering into an analyzer a circuit specification and tasks;

testing whether said tasks are performable in said sequential circuit when said sequential circuit conforms to said specification;

forming a refined specification by adding to said analyzer detailed information about said specification and entering a new tasks to be performed;

formally verifying that said refined specification preserves behavior of said specification, in that the response of said circuit to input signals when it conforms to said refined specification is consonant with the response of said circuit to the same input signals when it conforms to said specification;

replacing said tasks with said new tasks and said specification with said refined specification, and returning to said step of testing;

defining a reduction of said specification for each of said tasks to form a reduced specification for each task;

testing the reduced specification to determine that each reduced specification subsumes said specification and leaves its corresponding task invariant;

testing each task to determine that it is performable in a circuit that conforms to the reduced specification corresponding to the tested task; and

developing and delivering out of said analyzer structure information based on said specification, for effectuating said sequential circuit.

15. In a computer, a method for creating a sequential machine that conforms to a given specification, which machine performs tasks, comprising the steps of:

developing a refinement specification of said sequential circuit to form a refined candidate specification and defining tasks to be performed by said sequential machine;

testing the assertion that the refined candidate specification is subsumed by said given specification and that the tasks are performable by said sequential machine when said machine conforms to said refined candidate specification;

correcting said refined candidate specification and said tasks when said testing indicates rejection of said assertion;

replacing said given specification with said refined candidate specification and returning to said step of developing a refinement when said testing indicates acceptance of said assertion.

16. The method of claim 15 wherein said steps of testing and correcting comprises the steps of:

refinement testing, to confirm the assertion that said refinement is subsumed by said refined candidate specification,

correcting errors in said refinement when said refinement testing indicates rejection of the refinement testing assertion,

task testing, to confirm the assertion that said tasks are carried out by said refinement,

correcting errors in said refinement and in said tasks when said task testing indicates rejection of task testing assertion.

17. The method of claim 16 wherein said step of testing the assertion that said tasks are carried out by said refinement comprises a step of testing the assertion that said tasks are carried out by a reduced specification of said candidate specification.

18. The method of claim 17 further comprising a step of testing said reduced specification to determine that the behavior of said reduced specification subsumes the behavior of said refined candidate specification.

19. The method of claim 15 wherein said step of specifying a refinement terminates when, for a given set of possible input signals and target output signals, said candidate specification is sufficient to process said inputs signals and develop all of said target output signals.

20. The method of claim 15 further comprising a step of developing a set of control signals for embodying said sequential machine.

21. The method of claim 20 wherein said step of developing a set of control signals comprises developing a sequence of instructions for controlling a stored program controller.

22. The method of claim 21 further including a step of incorporating said instruction in a stored program controller.

23. A sequential circuit for carrying our given tasks, having a stored program processor and a memory, with a signal set stored in said memory having a portion that is essential for performing said given tasks, and said portion consisting of a plurality of modules, with each module forming a switch construct having references to no modules other than modules that control input and output functions of said stored program processor.

24. A controller comprising: a processor to form a finite state machine with an input port and an output port and which develops prechosen responses at said output port in consequence of input signals at said input port and the state of said finite state machine, having

an execution program for effecting said prechosen responses, and

a memory for storing said execution program,

wherein said execution program, in a portion thereof that is essential to effect said chosen responses, includes switch constructs, with branches of all of said switch constructs including commands selected strictly from a set that excludes calls to functions other than functions that interact with said input port and said output port.

25. Apparatus comprising: a finite state machine with an input port and an output port and which develops prechosen responses at said output port in consequence of input signals at said input port and the state of said finite state machine, having

an execution program for effecting said prechosen responses,

a memory for storing said execution program, and

a processor connected to said memory and to said input port and output port,

wherein said execution program, in a portion thereof that is essential to effect said chosen responses, includes switch constructs, with branches of all of said switch constructs including commands selected strictly from a set that excludes calls to functions other than functions that interact with said input port and said output port.

26. The apparatus of claim 25 wherein said execution program includes a concatenation of switch constructs, each of which with branches including commands that are selected strictly from said set.

27. A sequential machine, formed form a plurality of interacting finite state machines and having an input port and an output port, comprising:

an execution program to effect chosen responses of said machine at said output port to input signals at said input port,

a memory for storing said execution program, and

a processor connected to said memory and to said input port and output port,

wherein said execution program includes a switch construct for each of said interacting finite state machines, with branches of all of said switch constructs that are essential to effect said chosen responses including commands selected strictly from a set that excludes calls to functions other than functions that interact with said input ports and said output ports.

28. The machine of claim 27 wherein said switch constructs are concatenated.

29. A sequential circuit for carrying our given tasks, comprising: cooperating modules, where the structure of each of the modules forms a switch construct that is structured in accordance with an iteratively applied method comprising the steps of

developing a circuit specification to form a given specification;

testing whether said given tasks are performable in said sequential circuit when said circuit conforms to said given specification, and whether to continue to a step of forming a refined specification;

forming a refined specification by adding detailed information about said specification and defining new tasks to be performed;

verifying that said refined specification carries out said given tasks with the same responsiveness as those tasks are carried out by said given specification, in that the response of said circuit to input signals, when it conforms to said refined specification, is consonant with the response of said circuit to the same input signals when it conforms to said given specification;

replacing said given tasks with said new tasks and said given specification with said refined specification, and returning to said step of testing; and

developing said set of modules from said given specification.