Modular print engine assessment method using models

This invention relates to the field of printing machines, and more particularly to photo-duplicating machines such as copiers.

Today's machines, such as photocopiers, are often constructed from prefabricated components or components. Such manufacture enables mass production for each of the subassemblies of a machine while at the same time allowing for customization to the needs of the consumer. Furthermore, a consumer is provided with means that enable him to modify or enhance the capabilities of an existing base unit. Prior systems for distributed printing and distributed job scheduling can be found in US-5,287,194 and US-5,363,175. One point with regard to a modular design of integrated units is the configuration and optimization of the use of a completed system. While this is a point that concerns the manufacturer of a source unit, this may even be a larger area that affects the end user. End users are often technically inexperienced. However, they have a desire to expand the capability of a machine. At the same time, they would like to avoid increasing their initial investments. Consumers are also barred from costs associated with engaging a skilled person to upgrade or configure existing equipment.

Accordingly, it is the object of the invention to provide a method and system that simplify the configuration and optimization of printing presses. This object is achieved by the method as claimed in independent claim 1 and the system as claimed in independent claim 4. Preferred embodiments of the invention are subject matters of the dependent claims.

In accordance with one aspect of the present invention, a system is provided for generally and uniquely describing capabilities of various individual modular machine components.

In accordance with another aspect of the present invention, there is provided a system for integrating such generic component descriptions to automatically enable detection of the presence of one or more subassemblies and for communicating their various functional descriptions to a centralized processor unit for determination and analysis.

In accordance with another aspect of the present invention, the system provides an environment adapted for efficient, automated scheduling of a plurality of print jobs of different and varying characteristics. The present invention provides a method embodied in a printing press apparatus for determining an ability of the printing press apparatus to assemble a first product described by a first product specification, the method comprising the steps of: Providing a model for a press machine configuration, the model comprising an interconnected set of transfer functions characterizing the press machine configuration, each transfer function under this set of transfer functions representing a capability of at least one component device of the press machine Device Configuration describes to generate an input part from an output part; Performing an event-based backward simulation of the model by applying the first product specification on at least one output port of the model and determining an ability of the printing press apparatus to determine the first product described by the first product specification based on a result of the event-based backward simulation.

The present invention provides a new and improved technique for automatically determining a machine capability and using the same, which overcomes the above problems, and others, and provides a technique with increased usability and configurability both before and after the machine is used leaves.

The invention further provides a programmable printing system when suitably programmed, carrying out the method of claim 1, or according to any particular embodiment described herein, the system comprising a printing press, a processor, a memory and an input / output device. Circuit comprises. An advantage of the present invention is the provision of a printing press model that helps to be easily and automatically configured with respect to different or varying subassemblies.

Another advantage of the present invention is the provision of a printing machine adapted to be easily configured to a maximum potential by an end user.

Yet another advantage of the present invention is the provision of a printing machine that maximizes printing throughput by being adapted for efficient scheduling and utilization of modular sub-assemblies in accordance with user-specified print jobs.

Further advantages will become apparent to one of ordinary skill in the art upon reading and understanding the present specification. The invention may take a physical form in particular parts, and arrangements of parts, a preferred embodiment of which will be described in detail in this specification and illustrated in the accompanying drawings, which form a part hereof, and wherein:

Fig. 1 shows a schematic of a representative modular printing machine employing the automated configuration and scheduling of the present invention;

Fig. 2 is a flow chart detailing the hierarchical order of operations to carry out the configuration and scheduling of the present invention;

Fig. 3 is a diagram of a representative general description of a printing press component as used in connection with the present automated scheduling and configuration of the present invention; and

Fig. 4 is a block diagram illustrating an interaction of a scheduler and a control code using resources as provided in the present invention.

The invention is particularly applicable to a general description format for describing components independent of their environment or their interaction with other components. The system enables automated scheduling of print jobs according to the capabilities associated with modular components that make up a printing press, and will be described with particular reference thereto. However, it will be appreciated that the invention has a broader application, such as achieving an automated assessment of machine capabilities with respect to modular components, as well as an order specific usage in an efficient manner with respect to the same.

Turning now to the drawings, whose purpose is to illustrate the preferred embodiment of the invention only, and not for the purpose of limiting the same, FIG. 1 illustrates an embodiment of the present invention having a modular printing machine A comprising a plurality of modules or sub-assemblies B and a data processing unit for the configuration and scheduling C includes. As used herein, "printing machine" includes any reprographic machine such as printers, copiers, facsimile machines, and the like.

As will be explained in detail below, various capabilities provided with each of the modules B are fixed and correlated in the data processor unit C. Such correlated and analyzed data is further analyzed for user input defining a desired printer operation, or series of operations. This is in turn used to perform an operation or Optimize the operating mode of the printing press, schedule and control it in order to perform the series of printing tasks in the most efficient manner. The present system will be described by way of example in connection with a copying machine. It will be appreciated that the general description, resource estimation, and scheduling can be practiced on any modular material handling system.

In the particular example of Fig. 1, the modules B are illustrated as comprising a plurality of paper supply trays. As shown, these compartments include 10, 12 and 14. The plurality of compartments may serve different paper sizes or a secondary or reserved storage capability. A sheet feeding mechanism is shown schematically at 16. As will be appreciated by one of ordinary skill in the art, a sheet feeder such as that illustrated at 16 will function to obtain a sheet supply of one or more of the trays.

The feeder 16 will supply a sheet supply to a conveyor 18. The conveyor will in turn feed the sheet stock to a printing mechanism 20, the particular configuration of which will be within the understanding of those skilled in the art. Also shown in the figure is an inverting mechanism 13 which can selectively invert or deflect sheet material that advances along the conveyor 18. A recycle unit 32 is provided for returning sheet material to the printer mechanism 20 for duplex printing thereof.

In the illustration, the conveyor 18 provides a path to a stapling mechanism 34 for selective stapling of printed documents. The final component shown in the group of modules B represents a plurality of output bins, represented by shelves 38 and 40.

Turning now to the data processor unit C, it includes a data input / output ("I / O") unit 40 which is in data communication with a central processing unit ("CPU") / memory scheduler. Unit 42 stands, the details of which will be described further below. A data path is provided between the data I / O unit 40 and each of the modules B.

In the preferred embodiment, each module B therein includes a description associated with various functions and capabilities thereof. The details of such general description are given in detail below. The data path between each of the illustrated modules and the data I / O unit allows acquisition to the data processor unit C for the entire description. In the preferred embodiment, any module B will communicate its associated description to the data I / O unit under connection to the modular printing machine A. This feature enables the capability of "plug-and-play" the present system.

Data interconnections between the data I / O unit 40 and the data processor 10 and the various modules B also enable activation of a control unit thereof. As a result, the data processor unit C has received from the available modules the full set of capabilities of the modular press A. This information, coupled with the user input 44 to the data I / O unit 40, enables efficient scheduling of available, modular resources to perform a series of print jobs using the available components.

Referring next to Fig. 2, the basic format for general printing machine description and scheduling will be described. As indicated earlier, earlier attempts at scheduling software for an automated press were based on an analysis of a complete machine configuration. The results of this analysis are required to write associated software specifics to a particular configuration. In contrast, the present system is used to separate scheduling software into two parts. In the first part, a scheduler architecture is provided with general algorithms. In a second part, machine-specific information is also provided in a format detailed below.

Given a document to be printed on a given press, a scheduler is provided that identifies, schedules, and initiates machine operations to produce a document. In the illustration of Fig. 1, such operations may include feeding sheets, moving sheets, preparing images, transferring images to sheets, and so forth. It will be appreciated that a document to be printed typically arrives incrementally (e.g., sheet by sheet). Scheduling and execution (printing) usually take place simultaneously. As a result, machine-specific information used by a scheduler is advantageously structured such that the scheduler is able to identify which operations will generate the required sheet. Furthermore, the system must be aware of limitations that must be considered when scheduling operations. In addition, the system is provided with means by which it can send appropriate commands to the modules to enable them to perform their available functions. In the diagram of Fig. 2, a specific system for preparing the machine-specific information is shown. The system begins by using declarative descriptions (models) of printing press modules in block 100. Such a model advantageously includes a description of the structure of a module and the potential behavior of its components. As indicated in the example of Figure 1, possible components include feed chutes, conveyor belts, transmission components, inverters, gates, and so forth. For example, potential behaviors may either bypass an inverter or use it to invert a leaf. The step of model building is typically performed by an engineer using a modeling language, with the details of a preferred embodiment thereof given below. At block 102, a module has already been modeled by its components. Next, an automatic derivation of potential behaviors of an entire module from information obtained from the component models is created. This derivation is made, by way of example, by simulation or partial evaluation and by planning. As a simulation, conventionally, the execution of models is understood to reflect the execution of the real system. Partial evaluation is commonly understood to be the partial execution of programs, leaving some portions of the programs un-executed and to be evaluated at a later date. Planning is conventionally understood as the detection of all potential behaviors of a system by, for example, repeated and in various ways practicing simulation or partial evaluation of its models. The resulting modulus behavior is an output generated by a particular behavior, inputs from which the output is generated, individual operations required to generate it (its "route description"), as well as various constraints Reference is made to resources and timings observed when the operations are performed. Some or all of this information may advantageously be pre-assembled. By way of example, this can be assembled into finite state machines.

When print engine modules B (FIG. 1) are mated together to form a new configuration, different module behaviors are assembled and automatically assembled via the data processor unit C to generate potential behaviors of a complete press A. The above-mentioned composition is also suitably released to occur dynamically, ie At any point in time when the procedure is to be selected by the scheduler, it assembles module behaviors "on-the-fly". As a result, a composition can be made only once (after modules are first put together), or at any time they are needed. The latter option has the advantage of taking dynamic module changes into account. As a result, the system can implement the sequence of FIG. 2 complete at any time a machine behavior is selected. It can be a hindrance to do so because of the time-consuming calculations. However, this can be a more efficient measure in specific cases.

In block 104, as stated above, the overall behavior is modeled advantageously in a format similar to that associated with the behavior of the individual module, as noted above. In accordance with overall behavior, the system provides an output description (for behavioral identification), resource and timing constraints (for a sequence flow), and data having a route description (for subsequent control of machine operations). Next, a portion of machine behavior information is advantageously compiled for efficient use in an appropriate scheduler algorithm, at which point the system proceeds to block 106. As an example, an aggregation of potential interactions of timing and resource constraints with respect to a finite state machine may be made. An example of the scheduling of the finite state machine can be found in European Patent Application No. 96 302 570.5. At block 108, a full set of compiled behaviors has been obtained.

Finally, at block 110, an output description of machine behaviors is used by a general scheduler to identify behaviors that will generate a source document, specifying the original constraints (either in original or aggregated form). These are used to find a correct timing for each particular operation, a behavior and route descriptions used to initiate necessary operations of the B modules.

While the foregoing description has been given in terms of a preferred embodiment, it will be apparent that not all steps are required to provide a usable system. For example, only part of all components need to be modeled and a compilation of all constraints need not be performed.

With the system described above, modular ("plug and play") scheduling of printing press modules is facilitated. The system also allows the reuse of scheduling software for a wide range of configurations. It serves to automate all steps except that of obtaining the initial description of the discrete modules making up the machine and developing the general scheduling algorithms.

Referring now to Figure 3, a particular system for modeling a component behavior will be described. The particular system of the preferred embodiment is for describing a press component behavior for press analysis, simulation, and scheduling. As noted above, the general description method is equally applicable to various other modular systems.

In the present description method, a structure and a behavior of components are described in terms of capabilities (potential operations) for which limitations on work units, timings, and resources are indicated. This model-indicating system provides a structural and behavioral set of components for analyzing and simulating component interactions in presses. The system is particularly applicable to a scheduling operation of modular printing machines.

The present scheme may be used to describe printing press components so that printing presses made therefrom may be described by compilation of component descriptions. Furthermore, various applications may be automatically performed with respect to the resulting printing press description. This allows automatic use of such information for analysis, simulation, and scheduling, and thus related printing press applications. In the illustrated example of FIG. 3, descriptions associated with an inverter 150, analogous to the inverter 30 of FIG. 1, are provided with 150 '. Components of a model structure and a behavior are determined by both the physics of the components themselves as well as an application context in which a model is used.

In the system, a structural model of a component is defined to consist of its physical interface, software interface, and internal resources. For example, a physical interface is an input port 152 along which work units (blades) enter and an opening 154 from which the work units exit. An assigned software interface works primarily for control commands and parameters. Internal resources are defined as objects needed to perform a particular behavior, where multiple uses of the object are limited by repeated execution of the behavior. By way of example in FIG. 3, a resource is defined as the location of an associated gate 156. Another example of a resource is a space 158 between opposite exit rollers 160 of the inversion device 150, particularly shown at 150 '. Hereby, as at most points of the paper path, there is enough space for only one sheet at a single time. As a result, the space 158 is defined as a resource.

A behavioral model of a component is used to describe capabilities of the particular components with respect to how the component can operate in terms of work units moving through the component. Furthermore, the behavior dictates that constraints must be considered when performing the associated behavior. A component capability is defined to consist of a description of work units and a transformation of work units, timed events, similar to the input and output of a work item, resource assignments for that transformation, and timing constraints such events and resource assignments. Work units are advantageously described in terms of their attributes. Restrictions and transformations of work units are advantageously described in terms of limitations on their attributes. In Fig. 3, some additional model descriptions are given. These include a description associated with a particular unit of work, such as a sheet, shown at 164. A control situation, such as whether the inverter 150 is bypassed or not, or whether it is to be used for inversion, is shown at 166. For example, a timing parameter will provide a specification of path length and roll speed at 168. By way of example, associated timing constraints are conveniently obtained using a formula based on path length and roll speed, for example, where a time end can be defined as a start of time plus path length divided by the roll speed. Certain values ​​are also suitable parameters of the model, e.g. B. the path length of a given inverter is fixed while a roll speed can vary and therefore can be adjusted by the environment with respect to a model being used. A roll speed parameter is shown at 170.

By way of a specific example, the following listing provides a suitable model of inverting device, as illustrated in connection with FIG. 3:

This model provides two parameters (length and speed - length and speed), an entry port (in), an exit port (out), three resources (inR, outR and GateR, of types Signal respectively State) and six variables (of Types Sheet and Interval). Then the model defines two abilities (bypassing and inverting). For the "Bypass" capability, it is defined that a leaf s occurs at time t_in and exits at time t_out, that allocations are made in all three resources at the respective intervals t_in, t_out, and t_gate, and that different timing constraints, which reflect the time from entry to exit between the intervals. The Invert capability is similarly defined except that the sheet changes orientation 180 ° (rotated about the y axis) and the run time is longer (proportional to the size of the sheet).

Accordingly, it will be apparent that a full and functional description of any components may be similarly provided.

The disclosed model building system describes a component structure without reference to any reference to descriptions of or interaction with other components. Such a component behavior is described via a unit of work without other units. Furthermore, the disclosed model system enables automatic, behavioral composition of component capabilities for general and incremental analysis, simulation, and scheduling of printing presses. This description format allows automatic structural composition of component models into models describing connected components (for example, printing press modules).

Conversely, previous measures had expressed their capabilities and limitations with regard to both specific interactions between components as well as interactions between sequences of leaves or images. This makes them more difficult to define, makes them non-reusable, and still makes them non-composable. The system model format allows for automatic configuration, optimization, and scheduling, as described above.

As will be apparent from the foregoing, scheduling of a printing press is, in large part, scheduling of allocated resources. To do this effectively, one must model the resources used by a print engine operation so that information can be used for incremental scheduling of valid sequences of these operations. In addition, resources, being applicable in a wide range of printing press operations, may also suitably serve as general interfaces between a scheduler and the rest of the press control software for purposes of communication changes in the machine.

Components of a machine, such as a printing press, will usually require resources to perform their capabilities. By way of example, particularly with respect to a printing press, a resource may be a space on a tape, a door that must be in a particular position, or any element that serves multiple or overlapping uses. The capacity of a paper tray can be considered to be a case of such multiple or overlapping use.

Associations of resources are appropriately modeled explicitly as part of a description of a behavior of a component. As used herein, a resource allocation is defined as a description of a resource requirement, along with a time interval during which a particular resource is required. Again, by way of example, imaging capability requires space on a photoreceptor belt for a certain period of time. As another example, an inverting capability requires that an inverter gate be in a correct position while a sheet is to be inverted. As defined herein, a resource requirement is selected to be dependent on a particular type of resource. Possible resource types include such elements as Boolean resources (resources that are either used or not used), enumerated or state resources (staggered in one of the available states), capacity resources (where concurrent uses are added ), and the same. Such resource types are advantageously described generally by resource restrictions. Resource constraints themselves determine a consistency for multiple assignments for the same resource.

As an example, Boolean resource mappings, such as space on a tape, do not have to overlap in time. In contrast, state resource mappings may overlap if they require the same state. Capacity-resource allocations may overlap if the sum of requirements never exceeds a given capacity. Such resource types can be easily extended by changing or adding the resource constraints mentioned above.

Time intervals of resource allocations may suitably be associated with interval restrictions. As defined herein, a resource constraint system and an interval constraint system are orthogonal to each other. A description of resource allocations and timing constraints fit well into a compositional model pattern for scheduling.

Once all the components have been fully modulated, eventually a printing press will be moved to a runtime state. Referring particularly to FIG. 4, as can be seen, there is a scheduler 200 that is in data communication with a representative printing press module 202. The printing engine module 202, in turn, is constructed of various components, each using resources selectively arranged along a paper image path 204. Such resources are represented, for example, by components 210, 212, 214, 216, 218 and 220 (or their resources, respectively). Each of these resources is suitably described in the same manner, a representative of which is given in detail at 216 '. A system includes a control code area 220, a component / model area 222, and various communication paths. The control path 224 allows control commands to pass from the control code area 220 to the component / model area 222. Similarly, a sensor path 226 is for communicating sensor data in the opposite direction. A path 228 represents the scheduled use of resources by the component; more specifically, it stands for communicating knowledge of the model 222 describing the component to the scheduler where that knowledge is used to schedule correct uses of the resource. A path 230 is for control and sensor information to simply communicate with the scheduler 200.

At runtime, when operations are scheduled, the scheduler 200 initiates the interval so that the corresponding allocations for the same resources meet required resource constraints. This is also conveniently done by incrementally maintaining a trace of past resource allocations.

During a normal operation, the scheduler 200 considers only its own associations. To do this, she uses her model of the system to predict use of resources for operations that she has scheduled.

This system is also easily adaptable in terms of real time, a reactive environment, where resources sometimes become unavailable or limited in terms of a subset of normal capacity. Such variations in real hardware are typically monitored by control software of the module, which, in the example, is located in the control code area 220. It will be appreciated that in previous systems, with respect to the control software, it was required that it have a special interface to the scheduler to communicate deviations between modeled and real hardware, or to enable scheduler to have data of the controlled software.

A resource management within the scheduler 200 is suitably made accessible to an environment. More specifically, it is made available to a component control code as shown at 220. As with the scheduler 200, the control code 220 is then appropriately enabled to make calculations in such resources to reflect changes in the hardware. This in turn allows the scheduler 200 to automatically consider system changes.

In the above sense, models are used to define a pre-set behavior (resource assignments) of component capabilities. The control code itself dynamically tackles the behavior to reflect a current situation. This will be even further extended if an environment is allowed to change the resource constraints. Generally, this means that control software is considered to be controlling resources (starting from a default definition) while a scheduler uses such resources.

In an actual on-line implementation, a scheduler will advantageously make such future allocations automatically and take them into account. When the scheduler sees in the future to make further assignments, assignments are appropriately tagged with different priorities depending on whether they come from the scheduler 200 (respective models 222) or the control code 220. This automatically identifies any assignments made by the scheduler that are inconsistent with assignments by an environment and can be redone.

The present system provides a new and improved method to automatically derive the capabilities of a press configuration for scheduling and control software. By way of example, the capabilities of a print engine module may be derived from the capabilities of the components of the module so that a print engine may be configured from such modules, and the resulting print engine may be scheduled and scheduled.

The model building system, described in detail above, is based on a concept that printing press modules typically consist of components that perform certain operations on work units, and that a module is best described by describing its components and then deriving the description of the complete module is described by the descriptions of its components. In particular, model components are modeled to have certain capabilities that they can apply to work units passing through them. In a module such components are functionally connected. As a result, a module generates and operates work units by selectively moving such work units from their entry ports along the component-to-component connections and ultimately to their exit ports. During this process, each component applies its capabilities with respect to the work items. The capabilities of the complete module arise from the combination of such component capabilities.

Again, by way of example, a module may include components that move sheets of paper as well as images, transfer images to such sheets, bypass or invert such sheets, etc. One of the module capabilities arising from such component capabilities becomes suitable through a blank sheet of paper and an image entering the module and leaving the same sheet of paper with the image on it leaves the module characterized. This capability is further characterized by limitations in terms of work units (such as sheets and images) as well as resource constraints and timing of allocations in those resources, as may arise from the corresponding limitations in component capabilities.

As described in detail above, a component is modeled by describing its capabilities, each capability being described by defining which of the work units will enter and leave the component, which transformation will be performed on the work units, which attribute constraints have to be met in terms of the work units, which resource mappings need to be made and which restrictions on the timings of these mappings must be met. A configuration of these components (for example, a printing press module) is modeled by describing which components are used and how their openings are connected. Component ports are connected either to each other or to openings in the module.

Next, a method of deriving module capabilities from component capabilities will be described.

To derive a capability of a module of components, all components are started and recorded as waiting for input events. Then, an event consisting of a unit of work and a variable time interval is posted to one of the entry ports of the module. Next, one of the capabilities of the component associated with this opening is performed using this unit of work. During execution of the capability, attribute constraints (added to the constraints on the attributes of the work item) are executed, while the resource allocations and timing constraints are assembled in a constraint memory, and the name and arguments of a constraint memory Performed ability are stored in a route planning list.

Next, an event consisting of the (possibly transformed) unit of work and its exit-time interval is posted to an exit port of these components, and the component whose capability has been executed is restarted and again awaiting entry Events recorded.

If the exit port at which the exit event was posted is also an exit port of the module, a capability of the module has been deduced. Otherwise, the exit port is also the entry port of a connected component, and the step of performing a capability of these components is repeated as described above. In general, an ability may expect events at one or more of the entry port (s), and an ability may send events to one or more exit ports. A component capability can be performed if all the events it expects at exit ports are present. A module capability has been deduced when there are no events waiting at any entry port. It will be appreciated that the method of deriving module capabilities, as just described, may also be performed backwards by initially posting an event to an exit port and interpreting all capabilities backwards.

In such a method of simulating the operation of a module by performing the capabilities of its components, either forward or backward, module capabilities can only be derived if old events expected by the component capabilities are generated by one or more of the connected components , However, by way of example, when capabilities are derived in a forward-looking manner, a skill may encounter two or more input events, but until then only one has been generated and no other capability is expected, and therefore none other component can generate the remaining events. In such a case, capabilities of these connected components are executed, possibly "pretending" in a similar manner that their missing input events have been generated. This is repeated, if necessary, until the "fake" input events are posted to the module's entry ports. It should be noted that constraints need not have a predetermined direction, and therefore attribute and timing constraints may be implemented in any direction connecting appropriate input and output events. When the entire derivative described has been determined, the input and output events will contain operational unit descriptions that reflect inputs that are accepted and outputs that are generated by the module when the derived capability is performed.

It will be appreciated that, in addition to input and output events, the system may also consider control commands. This means that if the system does not start with only one or more events posted at module openings, but the user also provides a set of component capabilities to be executed, the system will also consider them. This set of abilities can be interpreted as either all (or exactly these) abilities should be executed (maximum) or at least the intended abilities should be executed (minimum).

Given such a method capable of performing component capabilities both forward and backward, it will be apparent that the mainstreaming is irrelevant for the purpose of deriving capabilities. Generally, whenever a derivative has not been completed, but events are still waiting for component openings, but a derivative can not proceed because one or more of the expected events on a component are still missing, then a component is selected, where at least one event has been posted at one of its openings, and the missing events of an ability of the selected component are assumed to be present; and are posted at the appropriate openings based on the definition of the ability. It should be noted that a preferred main direction of a derivative is often forward, but that a preferred aperture where the initial event is posted is often an exit aperture of the module.

It will be apparent that the described method works even when the module consists of exactly one component.

As noted above, resource allocations and timing constraints R are assembled in a constraint memory, and the names and arguments of executed component capabilities are stored in a routing schedule C during a derivation. This information, along with the accumulated attribute constraints and time intervals of all events I and O, posted to module entry and exit ports, respectively, are recorded as module capability <I, O, R, C>. The method described so far derives and records a module capability. This method is further extended with a prediction and traceability system. The system operates such that after a module capability has been deduced and recorded, it traces a drift back, failing to perform any of the capabilities it has previously performed and selecting another capability of the same components to execute. If no such capability exists or can be performed in consistency with existing constraints, the system continues to traverse until an alternative capability can be performed. From then on, a derivative continues. Similarly, if a derivative leads back to the initial dispatch of an event, events are posted to other module openings. In such a way, module capabilities can be derived and recorded. A derivation of all module capabilities is complete when all component capability alternatives in all components have been revealed for events at either all module entry ports or all module exit ports.

It should be noted that, especially when a module consists of more than one component, the resulting module capability information can often be simplified. For example, whenever two resources are of the same type and all assignments in that resource are linked by the same equality constraints in all module capabilities, the allocations in one of the two resources are redundant and can be removed without loss of information. Further simplifications will become apparent to those skilled in the art of limiting processing. If the module contains loops, it is possible that the system can not decide for itself when to terminate multiple iterations through the loops. In this case, or if no maximum set of component capabilities is provided as described above, additional functions that monitor the execution of at least one of the components may be provided by the user. By way of example, such a function may monitor a transfer component and only allow it to perform printing capability at most twice during a derivation. If such monitoring functions fail, such a derivative stops and tracks back. It will be apparent that there are various ways in which the system just described may be practiced. By way of example, such components may be executed as concurrent constraint programs generated from the models described in detail above and simulating component capabilities, and a module may be executed as a set of compound and linked such programs. Derivation is further performed by partially evaluating the programs; In particular, event actions and attribute constraints are evaluated while resource allocations and timing constraints are accumulated without interpretation. If necessary, the presence of events or commands is assumed by performing an abduction. Monitoring functions can be executed as controlling processes. This invention has been described with reference to the preferred embodiment. Obvious modifications and changes will become apparent to third parties by reading and understanding the description.