This paper deals with the development of customized and realistic manufacturing scheduling systems. More specifically, we focus onto a key element that may help driving their efficient design and implementation: I. E. , the set of building blocks that should include a generic scheduling system and its interconnections, a set collectively known as the architecture of a system. To do so, we first analyses existing contributions on the topic together with papers describing different functional requirements of scheduling systems.
These contributions are then discussed and classified, and a modular architecture for manufacturing scheduling systems is proposed. This proposal updates, extends and refines the well-known architecture proposed earlier by Pinned and Yen’s [Pinned, M. L. , Yen, B. P. -C. , 1997. On the design and development of object-oriented scheduling systems. Annals of Operations Research 70 (1), 359-378], and serves to integrate the different requirements identified in the literature review. ? 2009 Elsevier B. V. All rights reserved.
Article history: Received 20 April 2009 Accepted 17 September 2009 Available online 4 September 2009 Keywords: Scheduling systems Architecture Functional requirements 1 . Introduction While the literature on manufacturing scheduling models and solution procedures is extensive, very little NAS been written on now to bring these models and procedures into practice. This has given rise to the so-called “gap” between the theory and practice of scheduling (McCarthy and Lieu, 1993), which has been widely documented in several studies, such as e. G. , Ford et al. (1987), McKay et al. 1988), Laager and Rap (1995), Graves (1981), Duke et al. (1992) and McKay et al. (2002). In a quantitative study about scheduling research carried out by Irishman et al. (1997), from a total of 184 reviewed papers, only 5 (less than a 3%) dealt with realistic production settings. In order to close this gap between scheduling models and procedures, and their implementation in a real manufacturing setting, the former should be translated into a system supporting scheduling decisions in a company, I. E. , a piece of software with a number of functions to support scheduling.
This implies carrying out a software development process to obtain a final product, I. E. , a scheduling system at work. In such software development process, there are a number of technical, human and organizational issues which are critical and should be adequately managed to ensure a successful result. Among the different activities that must be carried out in the development of a manufacturing scheduling system, one of utmost importance is the design of the architecture of the system, as * corresponding author. Tell. : +34 96 387 70 07×74946; fax: +34 96 387 74 99.
E-mail addresses: [email protected] Us. Sees O. M. Framing), [email protected] Pup. Sees (R. Iris). 0377-2217/$ – see front matter ? 2009 Elsevier B. V. All rights reserved. Ii:10. 1016/J. Jeer. 2009. 09. 026 it largely influences the system’s subsequent detailed design and implementation. Moreover, parts of this architecture are common to most manufacturing scheduling systems, so relying on an effective, validated architecture helps reducing the usually costly and time-consuming development process while ensuring the quality of the resulting scheduling system.
Despite the importance of the architecture of manufacturing scheduling systems, scheduling research has often overlooked this topic, as the related literature is scarce and does not provide developers with a impressive view of the scheduling system, which clearly contributes to widen the aforementioned gap. Our paper is aimed towards this important issue. To do so, we first review the existing literature in order to identify contributions regarding descriptions of the architecture of manufacturing scheduling systems, as well as works describing the functionalities to be embedded in such systems.
We then propose an architecture for manufacturing scheduling systems that updates, extends and integrates the most relevant issues extracted from the analysis of the literature and those observed in practice. By doing so, our work intends to have a twofold contribution: On one hand we review and classify the contributions in the topic, while on the other hand we present an architecture for scheduling systems which extends the current descriptions and that is based on real developments.
While we do not claim that the proposed architecture is universally valid nor should be strictly followed, we hope that it will help directing the design of scheduling models towards a greater applicability. The remainder of the paper is as follows: in Section 2, we analyses the existing literature dealing with the structure and J. M. Framing, R. Iris / European Journal of Operational Research 205 (2010) 237-246 requirements of scheduling systems. Section 3 is devoted to providing a detailed discussion on the different functionalities of a scheduling system according to the analysis carried out in the previous section.
In Section 4, we propose an architecture of scheduling systems covering the most relevant issues extracted from the analysis carried out in the previous section. The paper ends by drawing some conclusions and pointing out future research lines. 2. Background Scheduling systems can be considered a particular case of business information systems. Usually, business information systems can be divided into packaged (standard) software, and customized software (see e. G. , Kerchief, 1999).
Although there are several standard scheduling systems available, the technological peculiarities of different production environments make it difficult to come up with a general-purpose scheduling approach (Brandied et al. , 2000), and quite often the code developed for the customization of a packaged scheduling software turns to be more than half the code of the final version (Pinned, 2007). As a result, the velveteen of a generic scheduling tool that can be widely installed has eluded the many vendors who have tried (McKay and Boycott, 2000).
Therefore, in the following we will focus on customized scheduling systems, although most of the discussion could also apply to standard scheduling systems. Broadly speaking, the development of a customized information system encompasses the following activities, which are independent from the adopted software development process (Kernel, 2008): Requirement analysis (or requirements engineering), I. E. , determining the needs of the information system to be developed.
Requirements are usually classified into functional requirements (those defining a function of the software), and non- functional requirements (those imposing constraints on the system such as performance requirements, security, or reliability). System design, I. E. , providing a conceptual solution to the requirements that have been identified. Usually, system design is broken down into (1) the description of the software components of the system and their relationships (what it is called the architecture of the system), and (2) the detailed design of these software elements Jacobson et al. 999). System implementation, I. E. , transforming the conceptual solution into a piece of software. System testing, I. E. , carrying out a validation and verification of the implemented system. Although customized manufacturing scheduling systems are, by definition, different for each company, it is clear that some activities in the development process may be common to all companies, as they refer to high-level descriptions of the purpose of the system. This is illustrated in Fig. 1, where generic (common) and specific activities are depicted.
While there are a number of compartmented repose for which a scheduling system can be implemented (see e. G. , Tug et al. (2005) for a classification of the different purposes of scheduling), most scheduling systems share a number of requirements, as all of them must have a number of common tintinnabulations. Since these requirements are retracted into components to the architecture of the system, it is clear that some parts of this architecture may also be common to most manufacturing scheduling systems. The re-use of an efficient, validated architecture instead of designing a new system from scratch has a number of advantages:
Fig. 1. Generic and specific activities in the development of a manufacturing scheduling system. It shortens the development cycle, as it saves time (and money) that otherwise should have been allocated to requirements analysis and design. It ensures that the main functionalities of a scheduling system are adequately covered, thus the architecture acts both as a checklist and as a design guide for the developers. It allows the re-utilization for future systems of part of the code developed, provided that the architecture is described in terms of blocks or function-specific modules.
There are several papers dealing with the architecture of manufacturing scheduling systems. These contributions range from high-level descriptions of the main components of a general-purpose architecture (such as in e. G. , Pinned and Yen (1997), Cocker et al. (1997), Diktat et al. (2005) or yen et al. (2004)), to detailed discussions about specific systems for a particular context (such as e. G. , Unman and Moratoria (1989), or Haddam et al. (1990)). Some papers concentrate on describing the structure of data handled by different scheduling systems with certain level of detail such as in _ Blackwell et al. 2001) or Rossi et al. (1998)), while others describe a hierarchy of classes referring to some of the persistent elements mentioned before (such as Saucer (1993), Natural et al. (1997), or Pinned (2007)). Given the lack of homogeneity among these contributions, a paper-by-paper description would offer little insight on the components discussed by the different authors. Instead, we have analyses these contributions and identified a number of functionalities that, according to these papers, must be covered by a scheduling system (see first and second columns in Table 1).
These functionalities are then grouped and described in Section 3, together with a discussion of the main contributions done by the different authors. In addition, we have also considered works discussing the mission of scheduling systems, and contributions presenting the requirements of scheduling systems. Even if most of these contributions do not explicitly mention the components that should constitute a scheduling system, they serve to establish the boundaries of such a system, and provide information about some functionalities that should/should not be included in the architecture.
Table 1 summarizes and lassies the contribution regarding these two types of works, which are described in detail in the next subsections. 3. Analysis of functionalities of scheduling systems In this section, we provide a detailed analysis of the different functionalities grouped by categories, according to the classification in Table 1 . J. M. Framing, R. Iris / European Journal of Operational Research 205 (2010) 237- 246 Table 1 Main contributions regarding the components of the architecture of a scheduling system.
Scope of the system The scope of a manufacturing scheduling system refers to the set of business functions targeted by the system. Generally speaking, there are two views or levels in scheduling, depending on the time horizon (Tug et al. , 1994): A higher level that uses the output of production planning to set up the dates for the beginning of each Job on each machine. This level is often referred as release scheduling. A lower level which is involved with real-time item movement planning. This level is usually denoted as reactive scheduling.
Note that these two levels should be adequately covered by the scheduling system, which meaner that a scheduling system’ architecture should integrate functionalities regarding the monitoring and execution of the planned schedules. This aspect is what McKay and Wirer (1999) label as “sustained control”, meaning that the schedulers should be able to monitor the progress of production and to solve problems if the actual situation deviates from he scheduled situation. In addition, there are a number of manufacturing activities that are related to scheduling.
Perhaps the most obvious is production planning, which covers production at a multi-week level and makes up the input data for release scheduling. Despite this clear connection, planning and scheduling activities are usually handled independently, except for a few attempts (see e. G. , Hung et al. , 1995; Kane and Deliberate, 1987; Ghana and Mallard, 1994). Indeed, it has been argued that many small shops have little scope to make long-term plans and that Yosemite complexities also force scheduling to be directed to very short-time horizons (Higgins, 1996).
Therefore, we will not include planning functionalities into our proposal, although it contains the necessary coordination between planning and scheduling. 3. 2. Problem modeling Problem modeling refers to requirements related to the meditation of the shop floor to be entered in the system and its corresponding schedules. Several functionalities regarding this area have been proposed: Model detection. This refers to the ability of the system to identify the cost suitable (theoretical) scheduling model from the instance data provided to the system.
Since most scheduling research refers to specific models (I. E. , a combination shop floor setting, constraints, and objectives) due to the complexity and inefficiency of general scheduling model representation and solution procedures, model detection may be an important feature of scheduling systems, as it may help selecting the most suitable algorithms to solve the problem or drive the development of new algorithms. This functionality is present in the e-COCA architecture (Taking et al. , 2005). In another contribution, Almanacs et al. 1988) develop a system that uses a metric to match scheduling problems. This functionality can be seen as an evolved functionality from the functionality “Schedule Capacity Instance” which is presented in Section 3. 6 (see in this subsection a discussion of the relationships between both functionalities. ) Constraints abstraction. This refers to the ability of the system to work with a simplified subset of shop floor constraints during the petition of the solutions for the scheduling problem, so constraints with a little impact in the evaluation of the solution are ignored.
This aspect, mentioned in Fox (1990), 240 may be regarded as a two-layer model since the representation of the constraints in the scheduling system is already an abstraction of the real constraints in the shop floor. Therefore, the system uses two layers (or views) of a problem: an aggregated view employed during the search of solutions, and a detailed one employed to represent the solutions. The suitability of the approach depends on ensuring that the constraints that nave been ignored do not nave a major detect in the testability so-obtained solutions. Representation of the solutions.
The solutions provided by he solution procedures have to be transformed into starting and finishing times for each Job. This functionality is mentioned by Pinned and Yen (1997) as “simulator”. 3. 3. Problem solving This subsection refers to the functionalities related to the solution procedures to be integrated in the system and how to use them. The following functionalities have been identified from the literature analysis: Algorithms for rescheduling. In many occasions, it is not possible to completely rebuild existing schedules, but it is preferable to perform a reschedule in which a subset of Jobs change their schedule.
In order to perform the rescheduling process, specific algorithms (usually considering extraterrestrial objectives such as minimization of the changes of the existing schedule) should be available in the system. This functionality is mentioned to be covered by a manufacturing scheduling system by several authors, including Blackwell et al. (2001), Collins et al. (1988), Lee et al. (1997), FOX (1994), Kemp (1994), smith (1994), Haddam et al. (1990), Saucer and Burns (1997) and Perpetual et al. (1994). Multi-algorithm scheduling.
This functionality refers to the separation of model and solution procedures, so different elution procedures can be applied to a given problem instance. This is usually denoted as algorithm library by several authors (see e. G. Pinned and Yen, 1997). The algorithm library should contain all algorithms available in the system for all scheduling problems that the system is able to deal with. Here we can distinguish between application-specific algorithms and generic algorithms. Application-specific algorithms are able to solve a particular scheduling problem, while generic algorithms may be employed for most (or all) the scheduling problems.
Both types of algorithms have advantages and disadvantages (see McKay et al. 2002) for a discussion on pros and cons of both options). Clearly, the algorithms for rescheduling described in the previous item could be seen as a part of the algorithm library. Generation of new algorithms. In order to make a dynamic and efficient use of the algorithm library, the system should allow for the integration of new algorithms in an easy manner. While this aspect is frequently mentioned in the literature, the proposed solutions range from a semi-automation of the process of generating new algorithms (see Taking et al. 2005), where a specific meta-language for describing scheduling algorithms is suggested), the description of an Application Program Interface (API) to embed the algorithms into the existing system (see the LIKEN system by Pinned (2008), where several general-purpose languages can be employed to be linked with the system), or the inclusion in the algorithm library of “chunks” of heuristics that can be combined to obtain new heuristics (see Saucer, 1993). Evaluation of algorithms. This functionality refers to the fact that the system must be able to choose/suggest the most suit- able algorithm required for any specific problem to be solved.
This feature may be squired by at least two reasons. First, it may happen that the specific problem instance to be solved does not match any of the problems that can be solved by the algorithms included in the library. In such case, the system can propose/choose employing algorithms that solve problems closer to the original. Secondly, it may be that more than one algorithm could be employed for the problem corresponding to the specific instance. Among these, the system should propose/choose the one(s) most suitable for the specific instance.
Several proposals have been done to capture the knowledge about the suitability of the algorithms. Saucer and Appellate (1997) suggest using the knowledge generated from solving actual instances of the problem (I. E. , past scheduling problems), while Taking et al. (2005) propose a mechanism to generate benchmark instances derived from actual instances of the problem to be solved that are subsequently employed to test the different algorithms. Finally, Guppy et al. (2000) propose the application of neural networks to select the best heuristic algorithm to solve a given scheduling problem.
In their paper, the objective is to choose the heuristic with higher statistical quality of the results. Incorporation of human expertise. This refers to the ability of the system to incorporate the knowledge of the human schedulers into the system. A list of the potential benefits of this functionality can be found e. G. , in Reminiscent et al. (1990). However, there is some controversy on the usefulness of the approach, since many researchers are skeptical that true human experts exist in scheduling (Stiffen, 1986).
This is motivated by the belief that most real-life scheduling environments are beyond the cognitive capability of most schedulers (Fox, 1990). Besides, even if human experts exist, some authors consider that the expert system would merely automate their (good or bad) decisions (Kane and Deliberate, 1987). As a consequence, the need/ suitability of this functionality is highly controversial. 3. 4. Solution evaluation This set of functionalities refers to how the solutions found by the problem solving functionalities described in Section 3. 3 are evaluated.
The following functionalities have been identified from the literature review: Evaluation of solutions for different objectives. The system must allow the evaluation of a solution with respect to several objectives, including a combination of different objectives. This functionality is mentioned by Pinned and Yen (1997) and Saucer (1993). Stochastic evaluation of solutions. The solutions obtained by the problem solving functionalities are usually based on deterministic assumptions, therefore it would be of interest to evaluate the performance of the solutions under the stochastic conditions of the real shop floor.
This functionality is _ suggested by Blackwell et al. (2001), who propose the use of queuing theory or simulation to accomplish this evaluation. Note, however, that this s only one of the approaches that can be employed to address variability in scheduling (see e. G. Black et al. (2006) for a summary of the different approaches). Analysis of scenarios. The system must allow the management of different solutions for what-if analysis. This functionality is particularly useful if the user is allowed to manually modify the schedules proposed by the system (see Section 3. For a discussion). It is mentioned in McKay and Wirer (2003). 246 241 5 Reactive scheduling This set to tintinnabulations raters to the ability to the system to perform reactive scheduling. Two different aspects can be considered: Monitoring of execution. While one option for the user is to decide whether to reschedule or not in view of the shop floor information found outside the scheduling system, the system could monitor the execution of planned schedules in order to measure the deviation between the planned and the actual situations, and trigger some alarm under certain conditions. This functionality is mentioned in Blackwell et al. (2001), Collins et al. (1988), Smith (1994) and Unman and Moratoria (1989). Automatic triggering of scheduling/rescheduling functions. A step beyond is to allow the system to decide, in view of the deviation from the plans, whether the current jobs have to be rescheduled, or a full schedule is to be developed. This fun_ seasonality is found in Blackwell et al. (2001), Collins et al. (1988) and Smith (1994). (1989), Perpetual et al. 1994), Saucer and Burns (1997), Saucer (1993), Saucer and Appellate (1997), Taking et al. (2005) and McKay and Boycott (2000). Note that this functionality should include mechanisms for repairing the possible infeasibility of the solutions generated by the human scheduler. Regarding the presentation of the solutions, hill Giant charts are mostly used as the primary mean for this interaction, Higgins (1996), questions its adequacy and suggests employing the so-called Job Screens and Michelangelo boards as a starting point. 3. 8.
Integration with existing information systems Integration in the organizational environment meaner that the scheduling system should be able to import the data required and to export the results obtained from/to the rest of the systems. A number of functionalities are discussed regarding this aspect: Input data checking. The system must provide functionalities to check he consistency of the data automatically entered into the system. Since these data are critical for the scheduling system and may come from many different sources of different quality, such checking functionality is of great importance (McKay and Wirer, 2003).
Feasibility analysis. The system can check the existence of all resources needed for scheduling the Jobs, namely the availability of raw materials, state of the machines, etc. This fun_ seasonality is mentioned in Blackwell et al. (2001) and Haddam et al. (1990). An important issue in order to accomplish a seamless integration of the scheduling system is to define a format or language that allows the precise specification of this data for a wider number of scheduling problems. Given the diversity of scheduling problems, this is not an easy task.
So far, some research has been carried out on languages for describing scheduling problems (see e. G. , Yen (1997), or Center et al. (1998)). However, keeping in mind the aforementioned need of integration of scheduling activities with existing manufacturing information systems, the development of a standard language is a must. In this line, perhaps scheduling systems can benefit from the XML standard and, more specifically, from he Business Process Modeling Initiative (BPML) (BPML. Org, 2004).
This initiative is seeking to establish an Assembled language and notation (BPML and BPML, respectively) for the specification of business process models. 4. An integrated modular architecture for scheduling systems As mentioned in Section 2, there are several references addressing a high-level description of the main building blocks of the architecture of a scheduling system. These blocks can be grouped into three sub- systems, which constitute the standard blocks to a decision support system, I. E. A database management system, a model based management system, and a user interface (see e. G. Pinned and Yen (1997), or Cocker et al. (1997)). We propose an extended modular architecture that contains a compromise between specificity and generality by adding important missing elements from existing proposed architectures, such as an explicit mechanism for handling the communication among the modules. This architecture also captures the reviewed functionalities from the previous section while giving enough details so to enable an effective design and implementation of a scheduling system.
More specifically, the scope of the proposed system entails both production scheduling and shop floor control, in accordance with the requirements identified in Section 3. 1 . 3. 6. Capacity analysis This set of functionalities refers to the ability of the system to detect critical points and slacks in the system, and can be grouped as follows: Schedule capacity analysis. By using this functionality, the system must be able to detect potential bottlenecks and undercoated resources according to the planned schedule (or even according to the actual schedule, if the system allows monitoring of execution).
This functionality may help the schedulers to focus their attention during the execution of the schedule into the critical sections of the shop floor, and to identify under-utilized resources to be loaded during the building of the next schedule, or transferred to the critical sections. This functionality is mentioned by Collins et al. (1988), Kemp (1994) and Perpetual et al. (1994). Instance capacity analysis. By using this functionality, the system may detect potential bottlenecks and under-loaded resources before a solution for the problem instance is provided by the yester.
Note that this functionality is different from that of schedule capacity analysis, as there is no planned schedule. This functionality is called preprocessor by Pinned and Yen (1997), and it can be linked with the Model Detection functionality described in Section 3. 2, since it can be regarded as a wizard to help identifying a suitable model for the shop floor (I. E. , a preprocessor that identifies that there is a bottleneck machine regardless the specific Job schedule may serve to point to the single-machine scheduling model as the most suitable model to schedule Jobs.