Towards Reusable Intelligent Scheduling Software Jürgen Dorn Institut für Informationssysteme Technische Universität Wien Paniglgasse 16, A-1040 Wien Email:
[email protected] Abstract Production scheduling plays a key enabling technique in improving the efficiency of modern production enterprises facing the international competition. Although the trend of software development for business application demands standard software, there exist no standard scheduling software package that can be applied to these applications. In this paper a special architecture based on object-oriented application frameworks and AI-reasoning methods is proposed as a mean to narrow this gap.
1 Motivation Modern production management has to face considerable organizational problems due to the shifting from mass production to more specialized small lot-size production. The production of smaller lot sizes and the requirements for fast reactions to market demands poses a manifold of constraints on the usage of available resources on the shop-floor level. To be competitive in the global market, companies must especially solve the efficient coordination in their production to avoid as much as possible of the so called hidden costs. The coordination of all activities that have to be performed to fulfill a customer’s order are a key process to eliminate these costs. Due to the diversity of products as well as the diversity of required resources such as human resources, machines, energy, and others, it becomes impossible to realize such scheduling systems with standard software. Each production unit is unique and requires dedicated solutions and moreover, it will change due to new production technologies available and changing market demands. Further, typically scheduling problems are NP-hard problems that cannot be solved easily. Knowledge-based scheduling systems were proposed to solve these knowledge-intensive problems (Fox 1987). However, such systems were commercially not as successful as expected. Although some systems were successful fielded (e.g. Dorn and Shams 1996), the effort to build them is high and moreover, they inhibit some drawbacks in system maintenance. A promising new software engineering technique are so called object-oriented application frameworks that offer reusable semi-complete applications that can be specialized to produce custom applications. An application framework is based on a domain analysis that states the basic assumptions on a number of related applications. The main inputs to a domain analysis are general theories of the domain and existing applications. In the following different techniques to support reuse of software are discussed. Two of these approaches rely on a domain analysis. The scheduling domain is then analyzed and a reusable framework able to incorporate theories of knowledge-based systems is presented. -1-
2 Reuse Techniques There are several techniques available that support the reusability of software. Three approaches namely • high-level languages • application generators • object-oriented application frameworks are presented in more detail here. Further approaches that seem to be not so important for scheduling are discussed in (Krueger 1992). 2.1 Reuse by High-level Languages High-level languages provide certain features that facilitate the description of scheduling problems on a high level of abstraction. By using such a language a developer must not consider certain implementation details and the “cognitive distance” between the problem and the formalization is smaller (Krueger 1992). Parts of the problem solving process may already be available by the system that interprets the high-level language. For scheduling problems three approaches exist that can be classified high-level language. Integer or mixed-integer programming (Garfinkel and Nemhauser 1972) is a high-level language in which optimization problems can be expressed by mathematical equations and inequations. This approach developed in the field of Operations Research is very general. There is a sizable body of literature which suggests solving scheduling problems by recasting them as integer programs. These recast problems may be solved by standard algorithms, which have been developed for solving general mathematical programs. A huge body of research has resulted in many improvements and very efficient algorithms for the integer programs over the last decades. Hence, translating a scheduling problem into an integer program, solving this program and translating the solution back, we obtain optimal schedules. Stated simply, this sounds a very promising approach; in practice it is not, because the standard mathematical programming algorithms are practically applicable only to small problems. Furthermore, to translate a problem profound mathematical background is necessary. Although existing standard programs apply general heuristics, it is always a considerable problem to apply domain heuristics in this approach. The second important approach is constraint satisfaction. Starting with the research of Fox (1987) many systems were developed based on this approach. The constraint satisfaction model allows a very natural description of scheduling problems especially the declarative description of legal schedules. Many improvements were made over the years so that today problems with thousands of variables can be solved in an acceptable time frame. Although constraints are a very natural concept for scheduling problems, one type of knowledge is not so easy to be represented by crisp constraints. In most scheduling problems there are one or more optimization functions. Several researchers have shown how constraint satisfaction techniques can be applied to single criteria optimization problems. However, the optimization function is not anymore declarative represented and the representation of multiple criteria is not addressed in these investigations. Another approach is constraint optimization in which constraint satisfaction plays a subordinate role. For example in our approach (Dorn and Slany 1994) and (Dorn et al. 1996) -2-
hard temporal constraints are handled implicitly by a specialized reasoning technique. They are considered as so fundamental for scheduling problems so that they are not a base of variation between different applications. Soft constraints are represented explicitly and they are a matter of optimization. The drawback of all high-level languages is that they all are designed only to solve the combinatorial scheduling problem. There are other aspects that must be handled by scheduling systems. Most important is the interaction with the user of the scheduling system. In most complex industrial applications the problem formalization can only be an abstraction because the reality is so complex and many aspects are unknown during the development of a system. Thus the user must always be able to overrule the system and change solutions proposed by the system. On one side this means that the system has to visualize its solutions in an appropriate fashion and on the other side the solution must be easy manipulatable by the user. Since the software is able to check for constraint violations more reliable than the human user, it should visualize also constraint violations to the user. Other aspects not addressed by the high-level languages is the interface to the environment and that of reacting to disturbances in the actual production process (i.e. reactive scheduling). 2. 2 Application Generators Application generators operate like programming language compilers – input specifications are automatically translated into executable programs (Cleaveland 1988). Application generators differ from traditional compilers in that the input specifications are typically very highlevel, special purpose abstractions from a very narrow domain. By focusing on a narrow domain, the code expansion in application generators can be one or more orders of magnitude greater than code expansion in programming language compilers. In application generators, algorithms and data structures are automatically selected so that the software developer can concentrate on what the system should do rather than how it is done. That is, application generators clearly separate the system specification from its application. At this level of abstraction, it is possible for even non-programmers familiar with concepts in an application domain to create software systems (Horowitz et al. 1985). Application generators are appropriate in application domains where • many similar software systems are developed • a software system is modified many times during its lifetime or • many prototypes of a system are necessary to converge on a usable product. In all of these cases, significant duplication and overlap results if the software systems are built from scratch. Application generators generalize and embody the commonalties, so they are implemented once when the application generator is built and then reused each time a software system is built using the generator. Application generators were developed very successful for high-level report generation, data processing, database management and data display techniques. In close relation to the scheduling domain is domain of the SAP R/3 standard software package which uses also the concept of application generators. Krueger (1982) also classifies expert system shells as a kind of application generator. Instead of reusing algorithms, expert system development with such shells focuses on reusing
-3-
common expert problem-solving methods. Thus diagnosing methods are applied for medical problems as well as for car maintenance. Several researchers have tried to identify such problem solving methods also for scheduling applications. However, it seems that there are no standard “expert” problem solving methods in scheduling. The main problem in scheduling is the inherent combinatorial complexity and problem solving methods must mainly address this complexity. In scheduling research a so called tool box approach were investigated by several researchers (e.g., Sauer et al. 1997). These systems try to provide all necessary data structures, algorithms and heuristics to the developer in a library from which the developer may select the appropriate ones. Although theoretically promising, the problem with this approach is that the developers of the tool-box must foresee which data structures and heuristics will become necessary eventually. 2.3 Object-oriented Application Frameworks Object-oriented application frameworks are a technology for reifying proven software designs and implementations in order to reduce the cost and improve the quality of software. A framework is a reusable, “semi-complete” application that can be specialized to produce custom applications (Fayad and Schmidt 1997), (Fayad et al. 1998). In contrast to earlier object-oriented reuse techniques based on class libraries, frameworks are targeted for particular application domains. The primary benefits of object-oriented application frameworks stem from the modularity, reusability, extensibility, and inversion of control they provide to developers. Frameworks enhance modularity by encapsulating volatile implementation details behind stable interfaces. Framework modularity helps improve software quality by localizing the impact of design and implementation changes, which reduces the effort required to understand and maintain existing software. The stable interfaces provided by frameworks enhance reusability by defining generic components that can be reapplied to create new applications. Framework reusability leverages the domain knowledge and prior effort of experienced users in order to avoid re-creating and revalidating common solutions to recurring application requirements and software design challenges. Reuse of framework components can yield substantial improvements in programmer productivity, as well as enhancing the quality, performance, reliability, and interoperability of software. A framework enhances extensibility by providing explicit hook methods (Pree 1994) that allow applications to extend its stable interfaces. Hook methods systematically decouple the stable interfaces and behaviors of an application domain from the variations required by instantiations of an application in a particular context. Framework extensibility is essential to ensure timely customization of new application services and features. The run-time architecture of a framework is characterized by an inversion of control. This architecture enables canonical application processing steps to be customized by event handler objects that are invoked via the framework’s reactive dispatching mechanism. When events occur, the framework’s dispatcher reacts by invoking hook methods on pre-registered handler objects, which perform application-specific processing of events. Inversion of control allows the framework (rather than each application) to determine which set of application-specific methods to invoke in response to external events.
-4-
3 Domain Analysis Both approaches, application generators as well as application frameworks rely on a thorough analysis of the application domain. A domain analysis is the process of identifying, collecting, organizing, and representing the relevant information in a domain to support reuse of software artifacts for systems to be built in this domain. The term was first introduced by Neighbors (1989). Domain analysis is based on the study of existing systems and their developing histories, knowledge captured from domain experts, and existing domain theory. Common objects and operations are likely to occur in multiple applications within a domain and thus are candidates for reusable components or classes. A domain is analyzed by studying several of its representative systems and by developing an initial view of the structure and functionality of these systems. During software development, information of several kinds is generated. One of the objectives of domain analysis is to make all this information readily available. When familiarity with the domain has been achieved and the representative systems are understood, information used in developing these systems as well as their common and variable parts are identified, captured and organized for later reuse in developing new systems in that domain. Domain analysis stresses the reusability of analysis and design, not code. This is done by deriving common architectures, generic models or specialized languages that substantially increase the power of the software development process in the specific problem area of the domain. Domain analysis can be seen as a continuing process of creating and maintaining the reuse infrastructure in a certain domain. A vertical domain is a specific class of systems such as the domain of scheduling systems. A horizontal domain contains general software parts being used across multiple vertical domains. Examples of horizontal reuse are operating system interfaces or string handling functions. Domain specific reuse is usually accomplished by separating domain engineering and application engineering. The goal of domain engineering is to identify objects and operations of a class of similar systems in a particular domain. Typical activities in domain engineering are domain analysis, architecture development, reusable component creation, component recovery, and component management. Application engineering means software engineering taking the results of the domain engineering process into consideration, i.e., identifying reuse opportunities and providing feedback to the domain engineering process.
4 Analysis of the Scheduling Domain In the following the scheduling domain is analyzed briefly and some of the core objects of any scheduling system are introduced. These objects can be realized in a framework as abstract classes as was done in DÉJÀ VU (Dorn et al. 1998). This analysis model is used later to show the application and reusability of intelligent reasoning techniques. We do not consider here the user interface or the interface to other applications which are of course also very important. 4.1 Order, Product, and Process Plan If we consider a typical scheduling process, the first object to be handled is an order. An order describes what shall be produced. Thus it must reference one or more products to be -5-
produced and some information how this product may be produced – i.e. a process plan. Products often are aggregated from different parts that must be handled differently during the production. Thus in the general case, we model a product as an object composed of different parts where a part may be itself a composite object. The composite design pattern (Gamma et al. 1995) can be used to model such products. Furthermore, an order may contain itself a group of products. Orders must be distinguished in client orders and production orders. A client order describes an order of one client that may contain several products that may not be produced together because some technological or efficiency constraints will prohibit this. A production order may also contain different products but these must be compatible (i.e. they must be producable together). Orders may also be grouped to reflect that they should be produced together because they are all compatible. Again, the composite design pattern is used here. The process plan describes a number of operations that must be performed on certain resources. It contains temporal information on the duration as well as knowledge about allowed sequences. Furthermore, allowed intermediate time periods when the product must wait or is stored in intermediate storages are described in process plans. 4.2 Resources One of the main concepts in scheduling is that of a resource. Resources are required to perform certain operations that are applied in order to produce some ordered product. From the view of an application many resources must be distinguished such as machines, tools, energy, personnel, and many more. Sometimes these resource types must be differenced still more to model certain characteristics of the resources. However, from the scheduling point of view the differences are not so great. To elicitate this differences we must investigate what a scheduling algorithm needs a resource for. A scheduling algorithm as well as a human scheduler will place operations on the resource giving them either a fixed starting point or some allowed time frame, when this operation is to be performed. Often the availability of the resource is restricted because the plant where the resource is located operates in a two-shift mode, holidays must be considered, or some breakdown or a maintenance period is to be considered. Such temporal availability should not lead to different resources but to configurable resources. Thus, resources have a calendar to describe their availability. From the scheduling point we can distinguish resources that allow only one operation at a time to be allocated and resources that can be used for more than one operation. For example available storage can be used for different products leading to different allocations with overlapping time intervals. In principle, resources that can handle only one operation at a time and the others can be managed with the same methods. However, the reasoning will be much more efficient when we define different allocation methods for both types. Thus, we identify non-sharable resources and sharable resources. Another type or resource that plays an important role are groups of resources. If we define such groups as an own type of resource we can easily define hierarchies where groups contain again groups. A resource group is necessary if a number of similar resources exist in an application. Then it will be a subproblem of the scheduling problem to find the best resource in the group for a given order (i.e. a routing problem).
-6-
4.3 Job and Allocation A job describes the performance of operations to fulfill a given order. Each operation is mapped to a so called allocation representing the association between an operation, a resource, and a time interval when the operation shall be performed. Jobs can also be grouped like orders. A job has a starting and a finishing time. Further attributes that may be present are a due date, release date, and more. Both objects are abstract objects that are used in every scheduling applications. For example, a job is scheduled or two jobs may be exchanged in a schedule. Consequently, there is an abstract job defined that can be refined for a certain application to reflect specialized characteristics of jobs in this application. The same holds for allocations that are put on resources and may be shifted, swapped or moved on a resource or in some cases also moved to another resource. 4.4 Schedule and Soft Constraints A schedule can now be seen as a number of resources to be filled with operations (allocations). Different schedule types should be distinguished to reflect different problem types. In scheduling theory (e.g. French 1982) job-shop and flow-shop scheduling are differentiated. In a flow-shop the resources are used for all orders in the same sequence. This reduces the combinatorial complexity some what and if we are to build a new application it is wise to apply specialized algorithms for a flow shop if appropriate. If schedules (i.e. solutions to a scheduling problem) shall be evaluated, different aspects must be “measured”. This can be done by soft constraints that are evaluated individually. The evaluation of all constraints associated with a schedule can then be aggregated in order to have a measure for the quality of the schedule. Although all constraints shall be aggregated into one measure, it makes sense to distinguish further some abstract types according to their appearance. So we distinguish between job constraints, allocation constraints, resource constraints and schedule constraints. The associated objects such as job and resource are now responsible for the creation, modification, and deletion of constraints whereas the scheduling object is responsible for computing the overall evaluation. A typical application dependent constraint is for example a tardiness constraint that evaluates how well a due date of a job is satisfied in a schedule. The creation is initiated by a job that has a due date and if the job’s finishing time is changed, it must also adjust the evaluation of the constraint. A schedule is, however, responsible to consider this value in the aggregated evaluation. 4.5 Scheduling Task and Schedule Improvement A scheduling task models potential modifications in a schedule. Some scheduling tasks describe methods how a job can be inserted into a schedule. Other tasks are used to model such modifications as moving allocations or jobs in the schedule. In principle, all actions a user should be able to do in a schedule should be modeled by such a task. A scheduling task follows the command design pattern (Gamma et al. 1995) thus supporting a common behavior of undoing and redoing actions. This design supports also the so called iterative improvement methods (Dorn 1995). This methods are based on the definition of a neighborhood of a schedule. A neighborhood can be generated by a method that decides which scheduling tasks are applicable on a given schedule. These methods are dependent on the type of the schedule, -7-
5 Incorporation of Knowledge and Knowledge-based Techniques The proposed architecture can be seen as a two-level architecture where the basic level applies techniques that come from model-based expert systems. For example, temporal consistency algorithms are applied to secure that schedules that are produced are always legal schedules. Also consistency of capacitive constraints are handled on this level. This level also provides generic methods to construct schedules such as explicit enumeration and branchand-bound search techniques. The drawback of such model-based techniques is that they are usually very complex, because most scheduling related algorithms are intractable in theory. For example, the branch-and-bound algorithm can only solve scheduling problems of a very restricted size. Thus, if we know certain simplifications or a heuristic appropriate for a subdomain or an application, we refine in derived classes the model-based behavior to enable acceptable response times of the scheduling system. Although such heuristics are applied we can still use some consistency mechanisms to enforce that produced solutions are legal. 5.1 Application-dependent Knowledge Some objects identified in the domain analysis will have very specialized attributes that cannot be foreseen in a domain analysis. Thus, if a new application is to be built this knowledge must be modeled in derived classes. One object for such a derivation is the order object. For almost every application a new order class has to be defined. One method that must be realized always is a read-method that knows how the order is to be read from a certain media. The objective is now that as few other classes of the framework as possible are dependent on such a derivation. The abstract factory design pattern (Gamma et al. 1995) helps to locate such changes to the single class. This means the derived order class acts as the concrete factory that has to construct appropriate objects required somewhere in the framework. Of course, object-oriented techniques are also an important means to localize such changes. For example, compatibility of orders plays an important role in the subdomain of steel scheduling. Thus an abstract steel order is derived that provides an interface containing a method that determines the compatibility of orders. Of course, this cannot realized for abstract steel orders. However, by declaring the method as pure virtual in a C++ realization, the developer of a new application will be forced to define this method if s/he wishes to derive an order from the steel order. 5.2 Scheduling Heuristics Since scheduling is usually an intractable problem heuristics are necessary in scheduling to find good schedules. We can identify different places where heuristics can be applied. The first kind of heuristic is used to select an order from the list of given orders to schedule it then. This heuristic can be based on the characteristic of the given orders or on the situation of the already scheduled orders. We may select first orders that are urgent or those that are difficult to be scheduled. A resource-oriented heuristic would select first these orders that are to be scheduled on resources that are identified as bottleneck resources. In the “MakeHeuristicSchedule”-method of the general scheduler class we define a general skeleton how a schedule can constructed heuristically. This method calls methods to select the most important order or to detect a bottleneck. In the derived scheduler class, we may either -8-
overwrite the called methods to reflect appropriate heuristics of an application or if necessary we may overwrite the “MakeHeuristicSchedule”-method. 5.3 Heuristics in Schedule Improvement We have defined several iterative improvement techniques such as tabu search or simulated annealing that can optimize given schedules. These techniques rely on the definition of scheduling tasks. Thus, for a new application we must define which tasks are appropriate. For certain types of schedules default tasks are defined. However, there is a great number of possible tasks and the efficiency of the improvement techniques rely on the size of the neighborhood. In the abstract core classes large neighborhoods are generated, because all defined scheduling tasks are tried in order to find a good neighbor. For tabu search where the whole neighborhood is investigated this means a great effort to find the best neighbor. For simulated annealing where only single neighbors are evaluated this large neighborhood means that the acceptance of bad schedules is relative high. These drawbacks can be improved by applying application dependent heuristics. Thus, we define a general “ApplicableTasks”-method in a flow-shop schedule and refine this method in an application schedule.
6 Discussion We have argued that for the requirements in modern production processes application frameworks are more suitable than high-level languages such as an explicit constraint satisfaction model because overhead to field such systems in actual applications is still to immense. Furthermore, it seems that for a domain such as scheduling where a great variation between applications exist, an application generator will be insufficient because not all required features can be forseen during the development of the generator. If such an approach shall be taken, the domain must be restricted more. The generator approach as well as the framework approach rely on a thorough analysis of the domain at hand. We have presented a reduced domain analysis. A complete analysis is in preparation, but this analysis still needs some input from other applications. We have a good overview on the scheduling theory, but it was detected in our application for the steel industry that in an application much more details have to considered than in theory is treated. Therefore this paper should also be understood as a discussion base to widen our focus on other scheduling applications.
7 References Cleaveland, J. C. (1988) Building application generators, IEEE Software 5 (4) pp. 25-33. Dorn, J. and Slany, W. (1994) A Flow Shop with Compatibility Constraints in a Steel making Plant in Zweben and Fox(eds) Intelligent Scheduling, Morgan Kaufmann, pp. 629–654. Dorn, J. and Girsch, M. (1994) Genetic Operators Based on Constraint Repair, ECAI’94 Workshop on Applied Genetic and other Evolutionary Algorithms, Amsterdam, August 9. Dorn, J. (1995) “Iterative Improvement Methods for Knowledge-based Scheduling”, AICOM Journal, pp. 20–34 . March 1995.
-9-
Dorn, J. , Girsch, M., Skele, G., and Slany, W. (1996) Comparison of Iterative Improvement Techniques for Schedule Optimization, European Journal of Operational Research, pp. 349-361. Dorn, J. and Shams, R. (1996) Scheduling High-grade Steel Making IEEE Expert February, pp. 28-35. Dorn, J., Girsch, M. and Vidakis, N. (1998) DÉJÀ VU – A Reusable Framework for the Construction of Intelligent Interactive Schedulers, Advances in Production Management Systems - Perspectives and Future Challenges -, Okino et al. (eds.) Chapman & Hall, pp. 467-478. Fayad, M.E. and Schmidt, D.C. (1997) Object-Oriented Application Frameworks, Communications of the ACM 40 No. 10, pp. 32-38. Fayad, M.E., Schmidt, D.C., and Johnson, R.E. (1998) Object-Oriented Application Frameworks: Implementation and Experience, Wiley N.Y. Fox, M. S. (1987) Constraint-Directed Search: A Case Study of Job-Shop Scheduling, London: Pitman. French, S. (1982) Sequencing and Scheduling – An Introduction to the Mathematics of the Job-Shop, Chichester: Ellis Horwood. Gamma, E., Helm, R, Johnson, R., and Vlissides, J. (1995) Design Patterns: Elements of Reusable Software Architecture, Addison Wesley, Reading, Mass. Garfinkel, R. S. and Nemhauser, G. L. (1972) Integer Programming, John Wiley. Horowitz, E, Kemper, A. and Narasimhan, B. (1985) A survey of application generators, IEEE Software 2 (1) pp. 40-54. Krueger, C.W. (1992) Software Reuse, ACM Computing Surveys 24 (2), pp. 131–183. Neighbors, J.M. (1989) DRACO: A Method for Engineering Reusable Software Systems, in Software reusability Part 1: Concepts and Models, Ted J. Biggerstaff and Alan J. Perlis (eds), pp. 295–319. Pree, W. (1994) Design Patterns for Object-Oriented Software Development, Addison Wesley, Reading, Mass. Sauer, J., H.-J. Appelrath, Bruns, R. and Henseler, H. (1997) Design-Unterstützung für Ablaufsysteme, KI 2, pp. 37-42.
- 10 -
