Abstract:
An expert system scheduler is disclosed which uses heuristics developed by an experienced factory scheduler. The scheduler uses these heuristics to generate schedules. Forward and backward scheduling is used at different stages of the schedule generation process.

Description:
FIELD OF THE INVENTION 
     This invention relates to a method of scheduling operations in manufacturing facilities and more particularly to an expert system scheduler for generating a detailed sequence of events to be executed on the floor of a factory. 
     BACKGROUND OF THE INVENTION 
     The effort to bring Computer Integrated Manufacturing (CIM) to factory floors has been motivated by the overall thrust to increase the speed of new products to market. One of the links to CIM is factory floor scheduling, which is concerned with efficiently orchestrating the factory floor to meet the customer demand and responding quickly to changes on the factory floor and changes in customer demand. Traditionally, factory floor scheduling has been a difficult problem to solve. Even after decades of research, management scientists have failed to find solution approaches which can be applied in practice to repetitive batch production scheduling. Most commercially available packages have not found generic application, because they are hard to customize to a particular plant situation and objectives. Also, some of the math-based scheduling packages require large computation times in their search for a near optimum solution. 
     SUMMARY OF THE INVENTION 
     In accordance with the present invention a scheduler is provided which schedules manufacturing facilities and more specifically generates a detailed sequence of events to operate the plant floor of a factory. The scheduler employs expert system techniques which lead to improved plant floor schedules under dynamically changing operating conditions. The scheduler was developed for application in the automotive industry, but is also applicable to other batch oriented manufacturing industries. 
     The scheduler utilizes various artificial intelligence (AI) based methodologies as well as a commercially available expert system shell. One of the primary features of the scheduler is its generic approach. That is, it doesn&#39;t matter what type of parts, machines or operations exist at the plant being scheduled. Among the many benefits of using such a system, are: reduced inventories, reductions in overtime, better utilization of equipment and user flexibility. 
     One of the features of the scheduler is the method in which schedules are generated. Rather than attempting to schedule various events while considering global data and constraints the scheduler generates the plant floor schedule in a multi-pass process. That is, events are scheduled in a manner that initially considers the most basic operating constraints within the plant. Then, in successive iterations or passes, additional constraints are invoked relative to the scheduled events. Events may be rescheduled to meet the constraint being applied if necessary. Thus, a plant floor schedule is built up in an iterative manner while satisfying all of the constraints in the system. Within the multi-pass approach there are additional features of significance. These include (1) scheduling preventive maintenance jobs (2) inventory versus safety stock usage (3) the concept of scheduling into negative time (4) scheduling Just-In-Time but allowing a user to pull the schedule early (5) selective, dynamic application of both forward and backward scheduling and (6) dynamic rededication of machines based on short term load. 
     Another feature of the scheduler of the present invention is its generic architecture. Data is maintained in specified knowledgebases. These knowledgebases are generic in the sense that they are used in all applications of the scheduler yet are internally unique to reflect the plant specific data. The five knowledgebases that are a part of the scheduler are generally named (1) model (2) orders (3) calendar (4) Gantt chart and (5) batches or trays. Although generic, the system can be customized to match the needs and objectives of the plant being modeled. For example, the model knowledgebase may be of an axle plant, the orders knowledgebase may be customer orders for the various axles produced in varying quantities and due dates. The calendar depicts the time each machine is available for production over the time horizon that the plant is scheduling. The last two knowledgebases, gantt chart and batches represent basic entities used in displaying to the user the generated schedule and for modeling batch sizes of parts to be processed. 
     Another feature of the present invention is the utilization of &#34;partial fits&#34; in the schedule generation process. Partial fits may be best described through the following example. Suppose a batch or lot of part A is scheduled from 12:00 to 12:30. Further, suppose that another batch of part A is scheduled from 12:50 to 1:20. Now, suppose it is desired to schedule another batch of part A and the desired start and end times are 12:15 and 12:45 respectively. It is obvious that this event will not fit entirely in the machine&#39;s idle time (12:30 to 12:50) as there is already a batch scheduled from 12:00 to 12:30. But, if this event is allowed to be scheduled at 12:15 to 12:45, the earlier event (12:00 to 12:30) can be rescheduled so that its start and end times are now 11:45 and 12:15. The event to be scheduled did not fit entirely in the original consideration but did partially fit. If the percent of partial fit exceeds a system defined parameter then the scheduler will allow this &#34;partial fit&#34;. More generally, the system is rescheduling some other events a little earlier so that the event currently under consideration can be scheduled near the desired times. 
     An area where the scheduler of the present invention is very useful is in merging an existing schedule with a newly generated one. This is an area where many scheduling systems fail. Since no scheduling system can instantaneously generate a plant floor schedule and implement it on the factory floor, consideration must be given to the delay between the time that a plant requests a schedule and the time that the generated schedule can take effect on the floor. It is uneconomical for equipment to sit idle while a new schedule is being generated if customer demand indicates the equipment should be utilized. The scheduler of the present invention permits the user to define how long to continue to follow the existing schedule or when to switch over to the new one. After that elapsed time, the newly generated schedule will be integrated and the plant floor can begin to operate under the control of the new schedule. 
     The scheduler of the present invention uses factory data related to three primary categories. First, is data having to do with parts that are produced in the plants. Second, is data having to do with operations, or those processes that are executed on a part, as it is being built. Finally, there is machine data defining which operations can run on which equipment. 
     An interface or preprocessor, between the scheduler and the source of the factory data, analyzes all of, the data and builds a model of the factory from which the expert system scheduler generates schedules. The basic requirements for the interface are to insure that all of the plant data is consistent and valid and to dynamically create the plant model. The scheduler then 1) generates a schedule for the plant floor which includes a time dependent sequence of events for each machine in the plant and 2) satisfies the customer orders. 
     The scheduler was developed using KEE, an expert system shell from IntelliCorp and the LISP programming language. The scheduler is driven by the requirement to build parts for customers. The scheduler initially assesses the available machine capacity (i.e. when machines can produce parts). Only the time available that can be used to produce parts on the machines is considered throughout the duration of the scheduling. Prior to back scheduling customer orders, the existing conditions in the plant are considered. One condition considered is the status of each machine. If machines are currently processing parts and/or committed to processing additional parts then those events are a constraint in the scheduling system. Further, if a machine is not available, or is in a down state, this factor must be considered as well. Once the current plant conditions are fully captured and comprehended by the scheduler the backscheduling of orders begins. The orders for parts to be scheduled are processed in a specific sequence. They are scheduled from the order with the latest due date back to the one with the earliest due date. The primary scheduling heuristics incorporated into the scheduler focus on backscheduling. Basically, backscheduling involves scheduling operations to be performed on a part, on the best available machine, from the final operation back to the initial or leadoff operation. This approach attempts to generate both a synchronous schedule and a just-in-time (JIT) production schedule. 
     Backscheduling begins with a chosen customer order. Next, the final operation for a specific part in the order is selected. Then the machines that can perform the operation are identified. The scheduler then determines the optimal time to schedule that operation given the events already scheduled at that point in time. The optimal time is defined as the time which permits a synchronous flow to the next operation with no required movement to and from a storage area. The scheduler also considers the consequences of setups or changeovers during the scheduling of events. The best choice for a process is made after all of the possibilities are evaluated. The criteria for selecting the best machine includes maximizing synchronousness, minimizing setups, scheduling batches of parts together and following machine dedication logic. This procedure continues for each operation for a given part in a customer order. The other parts in the order are then scheduled until the entire order is complete. Then remaining customer orders are scheduled until all of them have been scheduled. At this point the scheduler has produced a plant schedule that represents all events necessary to meet the customer demand for parts. 
     After a schedule has been generated for the plant, the scheduler considers current inventory and safety stock levels. These two areas represent on hand amounts of any given part at any operation. The scheduler uses the on hand inventory to improve the schedule. Safety stock is similarly used, but only in cases where orders are scheduled to be completed after their due date. That is, the safety stock is used in a much more cautious manner. It is intended for emergency situations, such as when a machine breaks down or when orders are expected to be completed late. 
     Next the system insures that the schedule is in fact feasible. It does this by shifting forward in time any events that were backscheduled to occur before the current time. Such infeasibilities can occur if there is not sufficient time available on the machines to build the parts or when too many customer orders need to be scheduled in the planning horizon. The shifting insures that all events will be scheduled at or later than the current time. In addition, during the shifting of the schedule forward in time, an attempt is made to minimize any lateness for orders by utilizing slack or idle time. 
     The next phase is to schedule preventive maintenance (PM) jobs on any machine that requires periodic maintenance. Typically, these jobs vary in duration from a few minutes to hours and must be performed at regular intervals. There is more flexibility in scheduling these jobs since they usually can be scheduled in a window or range of time. An attempt is made to schedule them in any existing idle time in the plant schedule. Basically, they are scheduled in the first available place where they will fit and not adversely impact already scheduled events. If no such place exists then they are scheduled where they will have a minimal impact on events that have been scheduled. Production events are rescheduled as required to make room for PM jobs. In any event, all PM jobs must be scheduled. 
     An optional feature, which pulls events earlier in time is also available to users. This capability, if used, will cause events to be completed earlier than they are needed and thus increase inventory levels in the plant. It can have positive implications in that if unexpected machine failures occur there is still a chance that the excess time (from pulling events earlier) will be sufficient to offset the downtime for the machine and still complete the order on time. This step merely tries to find idle time periods, earlier than where an event is currently scheduled, where the event can be rescheduled. It considers aspects such as minimization of setups as well as all possible machines that the process can be scheduled on during this phase. 
     The final functional area focuses on forward scheduling events. This method is essentially a mirror image of the backscheduling approach. Forward scheduling is applied within the scheduler in two areas. The first is for the replenishment of safety stock, which attempts to rebuild any safety stock used during the schedule generation. The second is for scheduling lower priority orders that are completed only if plant capacity is sufficient to do so. Specifically, forward scheduling looks for sufficient idle time to schedule a process and any required setups. Forward scheduling attempts to minimize additional setups with lesser emphasis on being synchronous. Forward scheduling will not schedule events that will cause any disruption to the customer orders already scheduled as they are of higher priority. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The above and other advantages of the invention will become more apparent from the following description taken in conjunction with the accompanying drawings wherein like references refer to like parts and wherein: 
     FIG. 1a and 1b show an overall flow chart of the factory scheduling method of the present invention, 
     FIG. 2 is a flow chart depicting the creation of the factory model, 
     FIGS. 3a-3b is a flow chart depicting the step involved in changing customer orders, 
     FIGS. 4a-4c show the backscheduling process, 
     FIGS. 5a-5c show the steps involved in using inventory and safety stock, 
     FIGS. 6a and 6b are a more detailed flow chart of the steps performed in adjusting a schedule which is not feasible as initially generated, 
     FIGS. 7a and 7b are a flow chart of steps involved in scheduling preventive maintenance, 
     FIG. 8 is a flow chart of the steps involved in front loading the scheduled operations, 
     FIG. 9 is a flow chart of the forward scheduling process, 
     FIG. 10a and 10b show the generation of reports and the output of schedule files, 
     FIG. 11 depicts information flow to and from the scheduler, 
     FIG. 12 shows a schedule in the form of a Gantt chart. 
     FIGS. 13a-13f are Gantt charts depicting six steps performed by the scheduler in generating a schedule. 
    
    
     DETAILED DESCRIPTION 
     Referring now to the drawing and initially to FIG. 11 the scheduler of the present invention is generally designated 2 and is particularly useful in a highly automated facility involved in automotive component production. The factory floor is controlled through a host computer designated the Factory Control System (FCS) 4. The FCS 4 receives factory floor status information from the factory floor as depicted at 6. In addition, the FCS contains current data on customer orders and on all expected material receipts as depicted at 7 and 8. All this information is sent through a computer network to the scheduler 2 whenever the situation warrants generation of a new schedule. A new schedule is generated and sent back to the FCS 4 for execution on the plant floor. The FCS 4 sends appropriate commands to the plant floor cell controllers for implementing the schedule. 
     The schedule is presented to the user in the form of a Gantt chart as shown in FIG. 12. The chart shows the schedule for an 8-hour period for a small department on a factory floor. The user can scroll the Gantt chart up and down if there are more than 24 machines, and right and left to look across the scheduling horizon. Successive operations of one particular batch of parts can be highlighted to follow its flow across the machines. In the chart the flow of a batch of parts is highlighted. The user can have the system generate the schedule step by step and follow its construction, or run all the steps together. The Gantt chart interface gives the user an understanding as to how the schedule is built and the overall performance. It also gives the user a quick means of evaluating the quality of the schedule. 
     Referring now to FIGS. 1a and 1b, an overall flowchart of the invention is shown. The initial step indicated at step 10 is to build a model of the factory from plant data files. Once the model is constructed the user is given the option of changing the existing orders or creating new orders as indicated at step 12. If changes are made the customer orders to be scheduled are updated as indicated at step 14. Thereafter backscheduling of the customer orders begins as indicated at step 16 and attempts to generate a just-in-time (JIT) production schedule at each operation in the production process. Next, as indicated at step 18, available inventory is used to improve the early part of the schedule. This permits later operations to be scheduled earlier and thereby free up machine capacity. After present inventory is considered, safety stock may be used as necessary to minimize any lateness relative to order due date(s). If as indicated at step 20, if the schedule generated is feasible, then preventive maintenance jobs are scheduled as indicated at step 24. By feasible we mean a) all orders are completed on time, b) all operations start after any current activities on each machine are completed. If the schedule as generated is not feasible, then the schedule is adjusted to take up any existing slack and thereby minimize the lateness of the orders as indicated in step 22, and preventive maintenance is then scheduled as indicated at step 24. The decision blocks at 26, 28 and 30 indicate an option that is offered to the user at different times to front load the schedule so events are scheduled earlier than a JIT schedule would dictate. In between these option offerings the safety stock is replenished as indicated at step 32 and low priority orders are scheduled as indicated at step 34. The low priority orders may for example be orders from other plants which could use any excess capacity that may exist on the machines. If the user exercises the option of front loading the schedule, the events are rescheduled as early as possible as indicated at step 36. Optional user reports may be generated as shown at step 38, which may for example be a machine utilization report indicating total production time, setup time and downtime for each machine in the factory. Various scheduling files covering the scheduling horizon are then generated as indicated at step 40. These files will include an activities file detailing a time ordered listing of what each machine is scheduled to do. The scheduling horizon is user defined and starts with build context time (BC in FIG. 13a) and ends with a user defined date and time such as for example two weeks after build context time. Build context time is the point in time when a snapshot of the factory was taken by the factory control system 4. Operations scheduled by the scheduler 2 may not begin before a user defined frozen time (FT1 in FIG. 13a) for each machine. Frozen time occurs after build context time and is a user defined time. Frozen time may be extended if a machine is currently processing a batch of parts on the factory floor and the process completion time extends beyond the user defined frozen time. 
     The initial step 10 of creating a model of the plant being scheduled is shown in greater detail in FIG. 2. As indicated at step 42, plant data including data relating to parts, operations and machines is read in from plant files. The data is examined for validity and discarded if invalid as shown at steps 44,46. As indicated at steps 48,50 52,54, and 56,58 the data relating to parts, operations and machines is used to build up the expert system knowledgebase of the factory. Part related information includes number of pieces in a batch or lot size and the routing (sequence of operations) to produce a part. Data may refer to a specific axle for example and include attributes such as batch size or routing. Operation data defines production time per part, setup or changeover time, lead time between operations, preferred machines for producing a part, and the inventory levels of each part (at each operation). The operation may, for example, be grinding and an attribute of the grinding operation would, for example, be cycle time or production time on a per piece basis. The machine data extracted from plant files includes machine status, availability, capacity and material handling times between machines. Customer order data is used to create a separate orders knowledgebase as indicated at steps 60,62. For example, an order may consist of 100 axles due on a specified date and time. 
     FIGS. 3a and 3b show the steps involved when a user wishes to change any data related to customer orders for parts. It is possible to make various changes to the customer orders if desired. As indicated in step 70, a menu is presented to the user with the options available. The various options are indicated at steps 72,76,80,84, and 88. If the user exercises an option, sub-menus are displayed to assist the user in carrying out the functions as indicated in steps 74,78,82,86, and 90. The user can then interact with the order entry system one or more times in the following manner. In steps 72 and 74 new customer orders can be created for any valid parts. Existing orders can be updated as shown in steps 76,78. This may involve modifying quantities ordered, updating due dates or adding new parts to an existing order. The user can delete orders as indicated in steps 80,82. In steps 84,86 the user may choose one or more of the existing orders to be scheduled. In steps 88,90 the user may save the new or modified orders knowledgebase. The user may exit the menu at step 92 by selecting the ABORT or DONE options as indicated in steps 94, 96. 
     The schedule is generated through a technique called backward scheduling. FIGS. 4a-4c show the steps executed. In step 100 the customer orders are sorted by due date with those due latest to be scheduled first. In step 102 a check is made to determine if all orders have been scheduled. If so, then the backscheduling process is complete as indicated at step 103. Otherwise, a check is made to determine if all batches of parts associated with the order currently being scheduled are completed. As indicated at step 104, if all batches of parts have been scheduled then control returns to step 102 to check whether there are further orders to be scheduled. Otherwise, step 106 identifies the next batch to be scheduled for the current order. As indicated in step 108, if all operations in the routing for the batch of parts are scheduled then the process continues at step 102 with the next order to schedule, if any. If all operations haven&#39;t been scheduled, step 110 selects the next operation of the part to be scheduled, which is the immediately preceding operation in the routing of the part. That is, the operations are scheduled in the reverse order of the sequence in which they are executed. Step 112 identifies which machines are capable of performing this operation. In step 114 the next machine in the list generated in step 112 is chosen for consideration. In step 116, the window of time during which it is desirable to schedule the operation, as well as the desired end time for the operation are determined. The desired end time is the date when the order is due if the final operation is being scheduled, or the start time of the succeeding operation minus any required material handling move time and/or any required lead time for the operation. The window of time to be examined is the product of process time of the operation and a user defined window span integer, i.e. the window time is a multiple of operation process time. For example, process time for a grind operation might be one hour and window span might be the integer 2, thus producing a window of time of two hours. Thus the window of time would begin two hours prior to the desired end time for the operation being scheduled. 
     Next, step 118 identifies the idle time periods that exist within the current window of time where the operation could potentially be scheduled. At step 120 a check is made to determine whether any idle time exists between successive events involving the chosen machine. If none exist then step 122 checks whether any other machines can be considered for scheduling this event. If other machines are available then control passes back to step 114 and the next machine to be considered is selected. However, if there are no other machines to be considered then step 124 checks whether any solution exists at this time. If not, then the time window to be considered in scheduling this operation is expanded in step 126 and control resumes at step 114 which chooses a valid machine to consider. However, if a solution did exist then the solution is implemented at step 128 and the process returns to step 108. 
     Now, if at step 120, idle time exists then the idle time periods in the window of time being examined on the current machine are considered as viable places to schedule the operation. Checks are made in steps 130 and 132 to see if the operation and any associated setups or changeovers will fit into the available idle time. If they won&#39;t fit entirely, or partially i.e. meeting a predetermined required percentage of fit such as for example 60% fit, then in step 134 the alternative is discarded from further consideration. Otherwise, step 136 collects the relevant solution data, .such as setups required, scheduled completion time for operation, total production time, and stores this data. This proposed solution is then compared with the current best solution, if one exists at this point in time, for the operation being scheduled. More specifically, step 138 checks to determine whether the assigned machine of the current solution is a primary or backup machine. A primary machine is one the user designates as preferable for a given operation. Backup machines are other machines capable of performing the operation. If the assigned machine of the current solution is a primary machine, or is a backup machine and the best solution&#39;s machine is also a backup machine as determined in step 140, then the process continues to consider the current solution. Otherwise, this solution is discarded from further consideration as indicated at step 142 and control returns to step 120. At step 144 a check is made to determine whether the current solution is within a user defined range of for example 15% of the desired end time for the operation. If so, the process continues at 146. If not, then step 148 checks the best solution relative to this same criteria. If the best solution to date isn&#39;t within the range then the current solution continues to be considered at step 146. Otherwise, the current solution is discarded at step 150 and the process continues at step 120. At step 146, a check compares the number of setups required for the solution being examined. If the number of setups for the current solution exceeds that of the best solution to date then step 152 discards the current solution and control returns to step 120. If the required number of setups is less than the number associated with the best solution then the system discards the best solution in step 154 and updates the current solution to be the best solution in step 156. The process now continues at step 120. This iterative process continues until all operations for all parts in all orders have been scheduled. At that point the backscheduling process is complete. 
     FIGS. 5a-5e show the steps associated with using available inventory and safety stock to improve the schedule. Initially, in step 170 a check is made to determine if there are any events expected to occur in the factory before the newly generated schedule can be implemented on the plant floor. If not, then step 172 initiates the process of utilizing inventory in the newly generated schedule. Otherwise, step 174 identifies scheduled operations from the existing plant floor schedule to verify that inventory exists to execute the operation First, in step 176 a check is made to determine whether the part operation is a leadoff operation. A leadoff operation is the first or initial operation performed on a part. If it is a leadoff operation then it can be ignored since there would be no productive part inventory required. If the operation is not a leadoff operation then a check is made at step 178 to see if there is available inventory to feed into the scheduled operation. If so, then inventory is used and decremented in step 180. If not, then the operation in question is deleted from the schedule at step 182. This iterative process continues until all of the operations from the previous or old schedule have been checked. Now the system can use the remaining inventory to further improve the operations for the newly generated schedule. As indicated in step 172, the various operations of all the parts are ranked from highest to lowest. That is, any leadoff operations are ranked low and final operations, like assembly, are ranked high. At step 184 a check is done to determine whether any of these operations have not yet been considered. If some operations remain then the next highest ranked operation is selected in step 186. At step 188 a check is made to determine if any inventory exists for that operation. If inventory does exist, then the next earliest scheduled operation that could use that inventory is identified at step 190. Steps 192 and 194 use and decrement the inventory appropriately. The process returns to step 188 to check whether any inventory still exists for this operation. This process continues until no more inventory exists for the operation and the process returns to step 184 where the next operation in the ranked table is considered. When this list is exhausted the system attempts to further improve the schedule by using any safety stock that exists. Steps 196, 198 and 200 are identical to steps 172, 184 and 186 executed during the inventory usage process. Further, steps 202 and 206 duplicate the functionality of steps 188 and 192, 194. The only difference in using safety stock is that it is only to be used to avoid or minimize any lateness of the customer orders That is, unlike inventory which is used until it is all gone, safety stock is used more cautiously. This is represented at step 204 which prevents usage of safety stock unless operations are projected to be late. 
     Referring to FIGS. 6a and 6b, a more detailed representation of the steps performed in block 22 of FIG. 1a is shown. Step 220 identifies which machines in the plant are capable of performing leadoff or initial operations on parts. Then based on the generated schedule these machines are ranked in step 222 from worst to best with the worst being that machine which has operations backscheduled furthest in time. These machines are considered one at a time in steps 224 and 226. The earliest scheduled operation is considered and a determination is made in step 228 of the amount of time the operation must be shifted forward in order to make the operation feasible. At step 230 the operation is shifted forward in time by the calculated amount. Idle or slack time is used during the shifting process for the operation to minimize lateness. Each succeeding operation on that machine is similarly checked at step 232 as described above and shifted accordingly. This process continues until the schedule for this machine is feasible. Now that a machine&#39;s operations have been shifted and they are feasible, a check is made at step 234 to determine whether any of the shifted operations have succeeding operations on other machines. If they do, these successor operations must be similarly shifted to maintain a feasible schedule and the process then returns to step 224. The above process repeats itself until all operations on all machines are feasible When all leadoff machines have been considered this process is complete. 
     FIGS. 7a and 7b show the basic steps involved in scheduling of preventive maintenance (PM) jobs. These jobs are scheduled after the customer orders have been scheduled for two reasons. First, the most important constraint for the factory is that customer orders be done on time. Second, PM jobs often have windows of time during which they can be scheduled. That is, a 15 minute PM job may be scheduled anytime during the course of a day. Thus, there is more flexibility in scheduling these kinds of events. Initially, step 250 identifies which machines have PM jobs that need to be scheduled. Then a check is made at step 252 to determine if all PM jobs have been scheduled. If so, then this process is complete. Otherwise, in step 254 the system chooses the next machine to be processed. In step 256 all of that machine&#39;s PM jobs are sorted by their required due date. Now the PM jobs are scheduled one at a time. First, a check is made at step 258 to determine if there is any available time to schedule the PM job. If there are no idle time periods in the window of time during which the PM job must be scheduled then the PM job must be forced into the schedule. Step 260 identifies the earliest desired place in the schedule and forces the PM job into the schedule at this point. Any jobs it affects, or overlaps must be rescheduled later in time. This is done in step 262 by simply rescheduling the affected operations forward in time. On the other hand, if there were places to schedule the PM job then a second check is made at step 264 to determine if the PM job duration will fit entirely into the available idle time. If the event fits completely into the available idle time then it is scheduled as indicated in step 266. If it does not fit completely, then the event is scheduled in the earliest idle time interval as indicated in step 268. In step 270 all affected events are rescheduled later in time. A check is made at step 272 to see if there are other PM jobs yet to be scheduled for this machine. If so then control returns to step 258. If there are no more PM jobs for the machine then control returns to step 252. This process continues until all machines have all necessary PM jobs scheduled. 
     FIG. 8 depicts the procedure for front loading a schedule. As previously indicated in FIGS. 1a and 1b this procedure is optional and is highly dependent on the operating goals of the factory being scheduled. The intent is to front load or schedule events earlier in time than they are currently scheduled. Although this tends to deviate from the Just-In-Time scheduling philosophy there are two reasons this may be desirable. First, typical factories of the present do not tend to operate with the JIT goals and objectives. Thus, there is a tendency to begin scheduling processes as early as possible. A second reason has to do with the reliability of equipment in the plant. When machines are frequently erratic in their behavior and unexpected downtime occurs often, a JIT schedule will in fact become late if this unexpected downtime impacts any of the scheduled events. Thus, with newer equipment, the JIT philosophy is often not emphasized until the machines are relatively stable and reliable in their performance. Step 280 collects all of the batches of parts that have been backscheduled. Next all of the associated operations for each of the batches are identified at step 282. Step 284 sorts the operations based on the scheduled start times of each operation. Beginning at step 286 the process will then reschedule the earliest event. In step 286 the next earliest event that has not been rescheduled is selected. Step 288 identifies all available idle time periods, if any, that exist in the schedule and are earlier than where the operation is currently scheduled. A check is made at step 290 to determine whether any idle time periods remain If not, then control passes back to step 286 and the next earliest operation is selected. If idle time periods exist then the earliest one is chosen in step 292. The earliest time period is checked at step 294 to determine if the event will fit into this idle time period. As a part of the check, any required setups or changeovers are also considered. If the operation and setups will not fit, then the process returns to step 290. If the operation does fit, it is rescheduled in this idle time period in step 296 and control return to step 290. This process continues until all operations have tried to be rescheduled earlier in time. 
     FIG. 9 represents the forward scheduling process. This process is applicable to both steps 32 and 34 of FIG. 1b but will be described with respect to step 32 for replacing safety stock. An attempt is made to schedule operations, given the existing constraints of already scheduled operations and machine unavailability. This procedure schedules operations in a forward manner (first operation, second, third, etc.) rather than in a backwards fashion as discussed relative to FIGS. 4a-4c. Step 298 identifies any batches of parts that need to be forward scheduled. The process will be used replenishing safety stock or scheduling lower priority component orders. Step 300 determines all operations for all of the batches identified in step 298. This is done by looking at the part routing to identity what operation must be performed to produce the part. The operations are sorted from highest to lowest at step 302. A check is made at step 304 to determine whether all operations, have been scheduled. If so then this pass is complete. If not then the next operation is selected to be scheduled in step 306. A check is make at step 308 to determine if any available idle time exists on any possible machine to schedule this event. If not then control returns to step 304. Otherwise, step 310 chooses the next idle time period for consideration. As indicated in steps 312 and 314, if the operation and any required setups will fit entirely within this idle time period then the event is scheduled and control returns to step 304. If not control returns to step 308. 
     FIGS. 10a and 10b show step 38 and 40 of FIG. 1 in greater detail. Referring first to FIG. 10a, step 320 displays a menu of available reports to review and analyze. In step 322 the user selects an individual report. These reports include machine utilization, inventory usage, part makespan, lateness and safety stock reports. Step 324 checks to determine whether additional reports are desired and if so control returns to step 322. 
     Referring now to FIG. 10b, in step 326 the output files are written to disk. The user is asked if he wishes to implement the newly generated schedule at step 328. If so, as indicated in step 330, the files are sent to the Factory Control System (FCS) which carries out the schedule. 
     Referring now to FIGS. 13a-13f, Gantt charts graphically depict the generation of a schedule. The scenario represented is a simple order for 150 front drive axles, to be processed in batches of 52 pieces each. In FIG. 13a the basic concept of backscheduling the events for a batch of parts is demonstrated. Note that seven vertical crosshatched boxes have been scheduled in the order numbered a-g. The assembly operation is first scheduled on machine ASSEMBLY2 at the due date for that batch of parts. Next, the polish operation is scheduled so that it ends just in time for assembly to start. This backwards scheduling continues on the boxes labelled c-g where g is the leadoff or first operation the part undergoes in the manufacturing process. At this point, one batch, or 52 parts have been scheduled through the factory. Next, another 52 pieces are scheduled in the same manner. These boxes are immediately to the left of the boxes a-g and are scheduled backwards from assembly in the same sequence as before. The size of each box is scaled to reflect the duration of the event. The other unshaded boxes represent batches of other component parts that make up the final assembled axle. The black boxes on the far right portion of the chart represent time that a machine is unavailable for production. This may be due to planned machine downtime or unexpected machine failures. 
     FIG. 13b demonstrates the impact of using available on-hand inventory to help improve the generated schedule. The system attempts to use trays, or batches, of inventory to improve the front end, or earliest portion of the schedule. This is demonstrated by the apparent disappearance of boxes from the chart. That is, if inventory is available then it is no longer necessary to schedule one or more batches of that part depending on how many batches of the part exist in inventory. In FIG. 13b some boxes that were formerly scheduled have been removed because of available inventory. A comparison to FIG. 13a will verify the prior existence of such events. 
     FIG. 13c shows the effects of shifting the schedule forward in time to insure feasibility. As indicated in FIG. 13a some events were scheduled before the solid dark line defining frozen time one (labelled FT1 on the bottom of the chart). This line designates the earliest time that operations can be scheduled. Thus, if any operations are scheduled before that time they must be shifted forward in time so that their start time is equal to or greater than FT1. See for example the sixth machine from the top of the chart, designated J&amp;L-6. It will be noted that these operations have been shifted or rescheduled from their positions in FIG. 13a, to start in accordance with the above constraint. 
     FIG. 13d illustrates the scheduling of preventive maintenance (PM) jobs. The PM jobs are designated PM in the chart. These jobs are scheduled around the already scheduled production jobs for customers. That is, the scheduler fits the PM jobs in as time permits. Production jobs can be shifted as necessary. Note on machine J&amp;L-6 that the PM job has been scheduled after two earlier scheduled events. The other PM jobs are scheduled similarly. The situation can become considerably more complex as the scheduling scenario becomes more complicated. A typical schedule would contain many more scheduled production events and also need to schedule many more PM jobs. However, the illustrated scenario conveys the general idea of PM scheduling. 
     FIG. 13e shows the replenishment of safety stock that might have been used in the process shown in FIG. 13b. Here, as in scheduling PM jobs, the operations are scheduled to satisfy the replenishment of safety stock as machine capacity permits. Effort is made to avoid impact on the existing schedule. In this process, operations are only scheduled if they fit into the available time completely. This is slightly different than PM job scheduling where a PM job will be forced in if necessary. The safety stock operations are highlighted by diagonal crosshatching on both the J&amp;L-1 and J&amp;L-6 machines. Reference to FIG. 13d will show that those events scheduled to the left of the crosshatched ones already existed in the previous schedule pass. 
     FIG. 13f shows the impact of front loading the schedule. During front loading operations are scheduled as early as possible without reference to Just-In-Time production. The particular scenario depicted in FIGS. 13a-13f has very few operations that can be pulled earlier in time. Two operations that can be scheduled earlier are horizontally crosshatched. In a real world scenario, the scheduler might reschedule hundreds of operations in this phase. 
     Attached hereto and forming a part hereof is an Appendix, comprising a source code listing written in Lisp with comments, showing an implementation of the invention. Software functions identified in the Appendix as kk.get.value(s), kk.put.value(s) and kk.remove.all.values are available from IntelliCorp Inc. ##SPC1## ##SPC2##