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: Jose@esi. Us. Sees O. M. Framing), rruiz@eio. 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 .
