RuleWorks

A Framework for Model-Based Adaptive Training

Scheduling Domain Overview

The KBS module for order scheduling is a piece of software which contains an agreed set of business scheduling rules and practices. Its function is to automatically place schedule dates on customer orders as they are received via a computer network into manufacturing from sales subsidiaries.

A schedule date is a commitment from manufacturing that an order will be shipped to a customer on the specified date. The scheduling of orders must be both responsive and reliable. The automatic scheduler uses rules to match demand (in the form of customer orders) to supply (in the form of capacity and material resources from a manufacturing plant's master production schedule).

Many rules look for scheduling problems – these rules are the eyes on the scheduling process; they pick out the exception cases. The scheduling rules are portioned in three main areas: rules for new orders, rules for change orders and rules for simulation & failure analysis. To facilitate easier update and maintenance of the rule-base, the KBS has been split into several modules, each performing specific tasks or functions.

The basic scheduling rule-types are as follows: rules which check that there are no conditions which would render the order unschedulable, rules to validate request dates on order lines, rules which find a manufacturing capacity slot, rules to facilitate splitting the order and schedule manufacturing of parts of the order, rules to change the target date if required, rules to detect scheduling failure conditions and rules to consume capacity and material resource allocations.

Scheduling Domain Analysis

This section presents a condensed analysis of the scheduling training problem. Training specification starts with a definition of requirements. For the order scheduling experiment the training purpose is to “improve order scheduling accuracy”. An analysis of the training domain produces a set of training topics and sub-topics. For example, scheduling new orders, prioritisation of orders, capacity time-fences, material lead-times and order slot reservation.

As in Proto-MOBAT, the analysis of training topics provides a ‘concept map’ of training ideas which can help in defining clear training objectives and tasks. In the MOBAT methodology, training objectives lead to training goals and realisation in problem spaces. The Scheduling-MOBAT work is based on an existing problem space structure shown in Figure 5-2. These problem spaces reflect possible training objectives. The sample training objective explored in this research is “to schedule orders”. A detailed training analysis which considers model-based training is needed in three areas:

  1. each training objective is decomposed into the tasks the trainee is expected to learn (subject specific and generic task decomposition);
  2. the classification of expected trainee goal expertise in a given problem space; and
  3. trainee profile characterisation.
Figure 5-2 Existing Problem Space Map

Figure 5-2 Existing Problem Space Map

Two subject specific tasks are used as examples in this chapter: “to check schedulables” and “to validate date”. The first task is to detect conditions which make an order unschedulable. This task is observing exception conditions, therefore it is characterised as primarily an interpretation task.

The second task is to validate the customer request dates for each item ordered against conditions, such as export hold lead times, slot reservation lead time and scheduling cut-off values. This task involves both interpretation of scheduling conditions and execution for calculating new target dates. All tasks include decisions as for each task it needs to be determined which rules to apply.

Task decomposition is about defining what tasks are needed, not how the tasks can be done. I.e., the action sequence of tasks to solve a problem is not fixed. As shown with RIME and Proto-MOBAT, the way to do a task can be realised with problem solving methods. A typical task sequence for the order scheduling objective and the number of rules for each task is the following:

to-check-schedulables (4 rules) Þ to-align-target (1 rule) Þ to-validate-date (12 rules) Þ to-find-capacity (5 rules) Þ to-find-material (3 rules) Þ to-detect-clash (2 rules) Þ to-realign-parts (2 rules) Þ to-consume-allocations (18 rules) Þ to-recalculate-allocations (4 rules) Þ to-reset-flags (2 rules) Þ to-report-scheduling (7 rules).

There are two categories that essentially define the suitability of a model based approach. The categories to be defined are (1) goal expertise based on 3 levels [Rasmussen 1986] and (2) the types of models available in the domain. If training objectives cannot easily be defined in these terms, then the MOBAT approach is unsuitable and alternative computer based training with flow-charting techniques might be more appropriate.

There is a variety of workers operating at different levels of order scheduling knowledge. The trainees can be production control, material planners, supervisors or order administration people. Many trainees are expected (to learn) to become highly skilled in order scheduling.

To perform the scheduling in a routine way the expected goal expertise is skill-based expertise. Other trainees need to deal with unusual problem situations and be knowledgeable about the scheduling principles. To cope with these trainee needs, rule-based expertise and model-based expertise is also required.

The knowledge for the order scheduling domain is already specified in a rule-based expert system therefore the available knowledge is termed associative knowledge. Below are two sample rules for the task to-check-schedulables which each have a simple conditional and a simple action part.

To-Check-Schedulables Rule # 1: Check for any lines on the order which have a hold reason code on them. A hold code is a number in the range of 1 to 49. If there are, then place a hold flag on the order header, and do no further processing. This check prevents any orders on hold being processed as standard orders.

To-Check-Schedulables Rule # 2: Check for any lines on the Order which have a Status Code not equal to the scheduling site’s Status Code and an unfilled Schedule Date. This check identifies any Lines to be supplied by another manufacturing group, for which no reply from that group has been received. If such a line is found, stop scheduling and analyse the problem later.

Task analysis has determined that the subject specific task to-check-schedulables is primarily seen as an identification task. When analysing the rules in their condition and action elements the scheduling rules can potentially be viewed as partly interpretation, partly identification, partly prediction, partly decision and partly execution.

The two rules above (to check schedulables) are primarily interpretation rules. There is a decision to be made in selecting the appropriate rule that should be applied. In both rules the decision would result in an end to the scheduling task for the current customer order. The first rule has a small execution part which is to place a hold flag on the order header and the second rule notes that the scheduling problem is to be analysed later.

*
Flower Show
  *  
© RuleWorks.co.uk | | Sitemap