Architecture of manufacturing scheduling systems - Semantic Scholar

European Journal of Operational Research 205 (2010) 237–246

Contents lists available at ScienceDirect

European Journal of Operational Research journal homepage: www.elsevier.com/locate/ejor

Invited Review

Architecture of manufacturing scheduling systems: Literature review and an integrated proposal Jose M. Framinan a, Rubén Ruiz b,* a b

Industrial Management, School of Engineering, University of Seville, Ave. Descubrimientos s/n, E41092 Seville, Spain Grupo de Sistemas de Optimización Aplicada, Instituto Tecnológico de Informática, Universidad Politécnica de Valencia, Valencia, Camino de Vera s/n, 46021 Valencia, Spain

a r t i c l e

i n f o

Article history: Received 20 April 2009 Accepted 17 September 2009 Available online 24 September 2009 Keywords: Scheduling systems Architecture Functional requirements

a b s t r a c t This paper deals with the development of customised 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 analyse 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 Pinedo and Yen’s [Pinedo, 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.

1. Introduction While the literature on manufacturing scheduling models and solution procedures is extensive, very little has been written on how to bring these models and procedures into practice. This has given rise to the so-called ‘‘gap” between the theory and practice of scheduling (MacCarthy and Liu, 1993), which has been widely documented in several studies, such as e.g., Ford et al. (1987), McKay et al. (1988), Olhager and Rapp (1995), Graves (1981), Dudek et al. (1992) and McKay et al. (2002). In a quantitative study about scheduling research carried out by Reisman 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 organisational 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. Tel.: +34 96 387 70 07x74946; fax: +34 96 387 74 99. E-mail addresses: [email protected] (J.M. Framinan), [email protected] (R. Ruiz). 0377-2217/$ - see front matter Ó 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.ejor.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 comprehensive 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 analyse the existing literature dealing with the structure and

238

J.M. Framinan, R. Ruiz / 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 customised software (see e.g., Kirchmer, 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 (Brandimarte et al., 2000), and quite often the code developed for the customisation of a packaged scheduling software turns to be more than half the code of the final version (Pinedo, 2007). As a result, the development of a generic scheduling tool that can be widely installed has eluded the many vendors who have tried (McKay and Buzacott, 2000). Therefore, in the following we will focus on customised scheduling systems, although most of the discussion could also apply to standard scheduling systems. Broadly speaking, the development of a customised information system encompasses the following activities, which are independent from the adopted software development process (Kurbel, 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., 1999). 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 customised 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 companydependent purposes for which a scheduling system can be implemented (see e.g., Aytug 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 functionalities. Since these requirements are reflected into components of 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., Pinedo and Yen (1997), Ecker et al. (1997), T’kindt et al. (2005) or Yen et al. (2004)), to detailed discussions about specific systems for a particular context (such as e.g., Numao and Morishita (1989), or Hadavi 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 _ Błazewicz 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 Sauer (1993), Maturana et al. (1997), or Pinedo (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 analysed 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 summarises and classifies 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.


239

Table 1 Main contributions regarding the components of the architecture of a scheduling system. Type of functionality

Functionality

Main references

Scope of the system

Production planning Shop floor control of schedules

Huang et al. (1995), Kanet and Adelsberger (1987) and Zhang and Mallur (1994) McKay and Wiers (1999)

Problem modeling

Model detection Constraints abstraction Representation of the solutions

T’kindt et al. (2005) Fox (1994) Pinedo and Yen (1997)

Problem solving

Rescheduling

_ Błazewicz et al. (2001), Collinot et al. (1988), Fox (1994), Kempf (1994), Smith (1994), Hadavi et al. (1990), Sauer and Bruns (1997) and Prietula et al. (1994) _ Pinedo and Yen (1997), Błazewicz et al. (2001), Kempf (1994), Smith (1994), Sauer and Bruns (1997), Sauer (1993), Sauer and Apelrath (1997), T’kindt et al. (2005) and McKay et al. (2002) Pinedo and Yen (1997) and T’kindt et al. (2005) Sauer (1993), T’kindt et al. (2005) and Sauer and Apelrath (1997) Reinschmidt et al. (1990), Steffen (1986), Kanet and Adelsberger (1987) and Fox (1990)

Multi-algorithm scheduling Generation of new algorithms Evaluation of algorithms Incorporation of human expertise Solution evaluation

Evaluation of solutions for different objectives Stochastic evaluation of solutions Analysis of scenarios

Pinedo and Yen (1997), Sauer (1993) and Sauer and Apelrath (1997) _ Błazewicz et al. (2001) McKay and Wiers (2003)

Reactive scheduling

Monitoring of execution Automatic triggering of rescheduling/scheduling functions

_ Błazewicz et al. (2001), Collinot et al. (1988), Smith (1994) and Hadavi et al. (1990) _ Błazewicz et al. (2001), Collinot et al. (1988) and Smith (1994)

Capacity analysis

Schedule capacity analysis Instance capacity analysis

_ Błazewicz et al. (2001), Collinot et al. (1988), Kempf (1994) and Prietula et al. (1994) Pinedo and Yen (1997)

User interface

Interactive scheduling

Collinot et al. (1988), Numao and Morishita (1989), Prietula et al. (1994), Sauer and Bruns (1997), Sauer (1993), Sauer and Apelrath (1997), T’kindt et al. (2005), McKay and Buzacott (2000) and Higgins (1996)

Integration with existing business information systems

Input data checking Feasibility analysis

McKay and Wiers (2003) _ Błazewicz et al. (2001) and Hadavi et al. (1990)

3.1. 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 (Aytug 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 means that a scheduling system’ architecture should integrate functionalities regarding the monitoring and execution of the planned schedules. This aspect is what McKay and Wiers (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 the 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., Huang et al., 1995; Kanet and Adelsberger, 1987; Zhang and Mallur, 1994). Indeed, it has been argued that many small shops have little scope to make long-term plans and that systemic 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 modelisation 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 most 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 unefficiency 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-OCEA architecture (T’kindt et al., 2005). In another contribution, Lamatsch 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 obtention 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 have been ignored do not have a major effect in the feasibility of the so-obtained solutions. Representation of the solutions. The solutions provided by the solution procedures have to be transformed into starting and finishing times for each job. This functionality is mentioned by Pinedo 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 occassions, it is not possible to completely rebuild existing schedules, but it is preferrable to perform a reschedule in which a subset of jobs change their schedule. In order to perform the rescheduling process, specific algorithms (usually considering stabilityrelated objectives such as minimisation 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 Błazewicz et al. (2001), Collinot et al. (1988), Lee et al. (1997), Fox (1994), Kempf (1994), Smith (1994), Hadavi et al. (1990), Sauer and Bruns (1997) and Prietula et al. (1994). Multi-algorithm scheduling. This functionality refers to the separation of model and solution procedures, so different solution procedures can be applied to a given problem instance. This is usually denoted as algorithm library by several authors (see e.g. Pinedo 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 T’kindt 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 LEKIN system by Pinedo (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 Sauer, 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 required 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. Sauer and Apelrath (1997) suggest using the knowledge generated from solving actual instances of the problem (i.e., past scheduling problems), while T’kindt 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, Gupta 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 Reinschmidt et al. (1990). However, there is some controversy on the usefulness of the approach, since many researchers are sceptical that true human experts exist in scheduling (Steffen, 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 (Kanet and Adelsberger, 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 Pinedo and Yen (1997) and Sauer (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 Błazewicz et al. (2001), who propose the use of queuing theory or simulation to accomplish this evaluation. Note, however, that this is 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.7 for a discussion). It is mentioned in McKay and Wiers (2003).


3.5. Reactive scheduling This set of functionalities refers to the ability of 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 Błazewicz et al. (2001), Collinot et al. (1988), Smith (1994) and Numao and Morishita (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 func_ tionality is found in Błazewicz et al. (2001), Collinot et al. (1988) and Smith (1994).

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 underloaded 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 Collinot et al. (1988), Kempf (1994) and Prietula 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 system. Note that this functionality is different from that of schedule capacity analysis, as there is no planned schedule. This functionality is called preprocessor by Pinedo 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).

3.7. User interface There are a number of functionalities regarding the user interface that are required for a generic business information system. Regarding those specific features of a manufacturing scheduling system, most authors highlight the need of human interaction (see e.g. the works by McKay et al. (1995), or Trentesaux et al. (1998)) meaning the manipulation by the human scheduler of the solutions offered by the system, an aspect mentioned by many authors, among them Collinot et al. (1988), Numao and Morishita

241

(1989), Prietula et al. (1994), Sauer and Bruns (1997), Sauer (1993), Sauer and Apelrath (1997), T’kindt et al. (2005) and McKay and Buzacott (2000). Note that this functionality should include mechanisms for repairing the possible unfeasibility of the solutions generated by the human scheduler. Regarding the presentation of the solutions, while Gantt 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 machineloading boards as a starting point. 3.8. Integration with existing information systems Integration in the organizational environment means 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 the 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 Wiers, 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 func_ tionality is mentioned in Błazewicz et al. (2001) and Hadavi 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 Zentner 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 the Business Process Modeling Initiative (BPMI) (BPMG.org, 2004). This initiative is seeking to establish an XMLbased language and notation (BPML and BPMN, 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 of a decision support system, i.e., a database management system, a model based management system, and a user interface (see e.g. Pinedo and Yen (1997), or Ecker 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.

242


The modules identified in the architecture are the following: Business Logic Unit/Data Abstraction Management Module. This module acts as a broker to guarantee the required abstraction when accessing to the data in the system. Database Management Module. This module stores the data in the system and provides a mechanism to interface with existing Business Information Systems in the company. User Interface Module. This module provides the required interface between the user and the scheduling system. Schedule Generator Module. This module contains all functionalities related to providing solutions to the user. A deployment diagram based on the Unified Modeling Language (UML) is given in Fig. 2. The proposed architecture is highly modular at all possible levels. All parts communicate through Advanced Programming Interfaces (APIs) and through the Business Logic Unit/Data Abstraction Module (BLU/DAM) in order to isolate the different modules. Otherwise, small changes in one module could have a serious – and sometimes difficult to predict or to spot – impact on other modules. The user interacts with the graphical User Interface, which should provide an abstraction layer over the database and scheduling algorithms. The user interface must be personalised for each scheduling setting as each production problem is unique (Pinedo, 2008). Interconnection with the company’s existing systems is carried out by the Database Management Module, which

is in turn only accessed by the BLU/DAM, providing a high-level of abstraction. All algorithms and routines related to scheduling are also isolated from the system and included in separated modules again only accesible by the BLU/DAM. One typical use case for a scheduling system based on the previous architecture is the following: information about the production floor is initially loaded into the application. From that point, the current production plan is created or loaded from the ERP or existing business information systems. The user selects the available resources, calendar constraints and all other significant aspects of the problem, along with the optimization objective. Once all data are loaded, the user selects the running time of the optimisation method (when possible) and generates a production sequence. Special importance is given to the graphical representation of such sequence since all vital information must be easily and readily available. Once again, this graphical representation contains a good deal of personalisation. Changes to several previous data elements should be allowed at some step, like on-the-fly changes of lot sizes, due dates, addition and/or cancelation of lots, etc. Usually, after a few iterations, the human scheduler will be satisfied with a final production sequence. The relevant data of this sequence must be again passed on to the ERP and all necessary reports must be generated. Once production starts, the optimized production sequence becomes the ‘‘current plan” that is therefore monitorised with the help of Supervisory Control and Data Acquisition (SCADA) production control systems. If production events occur, re-sequencing or

Fig. 2. Extended modular architecture.


re-scheduling might be necessary. Furthermore, future production plans are scheduled as per request of the user as a continuation of the current plan. In the next sections, we discuss in detail each one of the four modules proposed in the architecture. 4.1. Business Logic Unit/Data Abstraction Module This module mimics modern computer languages and development paradigms which insist on abstraction, modularity and encapsulation. Databases evolve over time, since new requirements often imply new fields and tables. The same can be said about the user interface. If a scheduling system is built in a monolithic way, a small change in the database could have a wave effect on many other modules. This would result in a system that is both very rigid and difficult to maintain. To ensure complete modularity and a high degree of independence, we propose the usage of elaborated class hierarchies that allow inter-module communication with published interfaces (like those available e.g. in the C# programming language). Notice that this architecture is very different from standard approaches where data is simply retrieved from databases and stored in memory structures. A distinct feature we propose is data polymorphism with which the same data entity might have different representations depending on the moment and intended use. Picture for example the entity that modelises a given quantity of a product to be produced. First of all, this might be referred to as a job, task, lot, production order and many other different names, depending on the company. Second, the data required to work with such an entity depends on the module. When visualising the production plan, detailed information like family, color or characteristics of the product to produce are required. However, for a given scheduling algorithm, the code of the job and processing time might be all that is needed. As a result, the type of interface published by a data class or entity to each module differs according to the intended use. With this architecture, the BLU/DAM acts as a hub between all modules, ensuring maximum expandability, flexibility and reusability. With the proposed architecture, it should be easy to provide a web-based user interface as a web-based IU could be easily plugged in to the BLU/DAM without knowing any detail of the other modules. Although the BLU/DAM does not directly incorporate any functionality, it includes the functionalities related to constraint abstraction discussed in Section 3.2. 4.2. Database Management Module This module contains three sub-modules, namely System Database, Production Monitoring, and Import/Export/Synchronisation. Among these, the most standard one is the System Database, which contains all necessary persistent data. Modern relational databases are perfectly capable for this task. However, large databases require some extra efforts in order to assure a responsive system. Existing architectures, like the aforementioned by Pinedo and Yen (1997) fail to address important aspects of the database management which can be of paramount importance for an effective and real implementation of scheduling systems. Some important data will have to be retrieved from existing information systems and ERP software. Usually, this information is not complete, specially if the company is implementing a third party production planning/scheduling software. As a result, some additional data will have to be introduced into the System DB, which in turn adds the necessity of keeping consistency of this data with the ERP system. Keeping this consistency is extremely complex and requires an specific module to import, export and to synchronize the Business Information System with the System DB. This module can

243

incorporate the Schedule and Instance Capacity Analysis functionalities discussed in Section 3.6. The last submodule is concerned with production control. As we will see later on, controlling the current production program requires of special features. SCADA systems and in general, the business information systems of the company contain manufacturing execution control software that generate real time information. This information is urgent and must be dealt with rapidly. An import/export/synchronize module that carries out lengthy operations in batch mode in order to keep up to date the System DB is not appropriate for real time data management. As a result, an ad-hoc module must be written in order to load real time production control data. This data is then interfaced to the BLU/DAM and the necessary events are fired in order to notify all other modules that real time data has been received. Together with the BLU/DAM, this module can incorporate the functionalities to perform the monitoring of execution (Production Monitoring submodule) as required in the analysis of functionalities carried out in Section 3.5.

4.3. User Interface Module Although this module might seem straightforward, it is indeed one of the most complex modules in the architecture. Effective, complete and easy to work with visualisation is a hard task that requires extensive coding. This comes as no surprise, since different scheduling problems require not only different solution procedures but also equally varied and complex solution representations. This module includes all functionalities mentioned in Section 3.7 and the representation of solutions mentioned in Section 3.2. We identify five submodules inside the user interface, i.e., Output Representation, Scenario Management, System Maintenance, Scheduling Control, and Algorithm Generator Interface. Regarding the Output Representation submodule, obviously, once a solution for a given scheduling problem or production plan has been obtained, it has to be visualized. Detailed and interactive Gantt Charts, machine, section and plant load charts, statistic pages and performance criteria sheets must be provided, among many other possible data visualisations. All this information should be easy to understand. Furthermore, the first thing the user is going to try to do is to change the results. Drag and drop and easy manipulation of the output must be provided. Some of the changes might trigger a need for complex calculations or even to some small schedule repair or re-scheduling algorithms. As soon as the user changes input data or the given solution to a scheduling problem, a new problem is created as a result. Eventually, the user will require that all these problems are confronted in order to study the different trade-offs. To a certain extent, each new problem or situation can be seen as a scenario and all created scenarios must be managed by the User Interface. Let us not forget that once a scheduling system is available to the user, more and more strategic decisions can be taken. For example, questions like: What would be the result with an additional machine? What if I cancel the night shift? can be answered with an Scenario Management submodule. This submodule incorporates functionalities mentioned in Section 3.6 and, more specially, the analysis of scenarios from McKay and Wiers (2003) and reviewed in Section 3.4. Of course, all the persistent information in the System DB must be maintained, from the configuration of the shop and existing machines to the detailed production characteristics of each product. This is the main goal of the System Maintenance submodule. As simple as this might seem, the sheer amount of production data often results in a cluttered user interface. In order to be usable, maintenance screens should be easy to work with. We advocate the usage of simple data wizards and automation tools. For example, when purchasing an additional parallel machine, it is surely easier

244


to copy an existing one and later specifying the small differences than to introduce a new machine from scratch. Regarding the Scheduling Control submodule, it is to note that real time data coming from the BLU/DAM must be handled independently. Should the current schedule receive an event from the production floor, this event must generate a visual warning to the user. Once this warning is accounted for, a detailed report of changes to the current schedule should be provided. Some of this information is needed in order to cope with functionalities mentioned in Section 3.8. More specifically, input data checking and feasibility analysis must be confronted upon each new scenario. Last but not least, the scheduling system should allow for the creation of new algorithms. In order to hide the small details of the algorithms to the user, a friendly interface based on wizards is preferable, which is foreseen in our proposal to be the goal of the Algorithm Generator Interface submodule. The functionality of new algorithms was put forward in Section 3.3. Summing up, the modules described in this section address a number of functionalities discussed in the previous sections: In addition to the representation of the solutions (see Section 3.2) which is covered by the Output Representation submodule and the capability that the scheduler manipulates the solutions found by the system (discussed in Section 3.7), the proposed architecture sets up the basis for an intuitive generation of new algorithms (see Section 3.3) by using the Algorithm Generation Interface submodule, and eases the analysis of scenarios (see Section 3.4) by employing a submodule for Scenario Management. Finally, functionalities referred to reactive scheduling (see Section 3.5) are foreseen by the submodule Scheduling Control. 4.4. Schedule Generator Module This module contains four main submodules, i.e., Algorithm Library (which in turn may be divided into Scheduling Algorithms and Rescheduling Algorithms), Algorithm Generator, Scheduler & Dispatcher, and Preprocessor. In order to be adaptable, the optimisation algorithm must work on an abstraction of the scheduling model, or better, on an abstraction of the representation of a possible solution. For example, a typical permutation flowshop solution for makespan criterion can be represented with a simple permutation of the jobs. The detailed schedule with all the start and finish times of every task is many times of little relevance for the optimisation methods. As mentioned before, these abstractions are provided by the BLU/DAM. Notice that once the solution to a problem is returned to the BLU/DAM, a complete and much more detailed schedule might be built by the User Interface Module. What should be mentioned as a part of the architecture is the separation of all non-essential constraints from the schedule generation process. Many constraints can be accounted for when the detailed schedule is constructed. Of course some level of accuracy will be lost in the process but it has to be carefully studied whether this decreased accuracy is compensated by a more general and adaptable optimisation method. In order to reflect this, we separate the Algorithm Library submodule from the Scheduler & Dispatcher submodule. A given – and more general – algorithm produces an optimized production schedule where all major constraints have been considered. In a second step, the Scheduler & Dispatcher submodule produces an even more detailed schedule where minor constraints are also considered. By operating in this way, the scheduling system might accommodate new constraints and new situations in a more flexible and agile way. Similarly, the number and variety of optimisation criteria or performance measures found in practice is extremely large. As a result, for the calculation of the performance measure for a given solution, a two-stage approach is preferable. In the first stage, a de-

tailed schedule is derived from the abstract representation of the solution. All relevant data, and most importantly, completion times of all tasks, are calculated. In a second step, specific performance criteria are derived from the completion times calculated in the first stage. This two-phase approach allows for a large flexibility and independence when defining new and ad-hoc criteria. With the previous premises, a given scheduling algorithm does not need to know in detail neither the specific constraints and small details of the underlying model nor the particular scheduling criterion. Notice also that the algorithm library should contain not only full-scale optimization algorithms but also some smaller schedule repair and re-scheduling algorithms that might be invoked by the User Interface Module as a result of changes in a given solution or as the response to events in the production floor. Examples of these specific approaches are summarised e.g. in Li et al. (2000). We would like to point out an important issue here. As of today, and according to our experience, most companies are using extremely simple scheduling methods like list algorithms, if at all. Therefore, when implementing and deploying a new scheduling system, the focus should not be on the accuracy and effectiveness of the optimisation algorithms as these are likely to outperform human schedulers in many scenarios. Conversely, special care should be put on assuring the success of the scheduling system as a whole by providing flexibility and expandability. Among the algorithms, there is a broad distinction between specific algorithms and generic algorithms. Specific algorithms are designed for solving a particular model, while a generic algorithm may be applied to a wide range of scheduling problems. In practice, most commercial scheduling systems employ general-purpose algorithms, such as genetic algorithms or tabu search (e.g., SAP-APO employs genetic algorithms). As mentioned, both types of algorithms have advantages and disadvantages. However, there are some reasons for not overlooking specific algorithms: Exact algorithms. With the increasing power of computers, more and more problem instances may be solved by exact algorithms (i.e., enumeration methods). Typical generic algorithms for exact methods are based in integer programming models that are relaxed into continuous models in order to obtain bounds to perform a branch and bound method. However, it is known that, for most scheduling problems, such bounds are extremely bad and therefore are not efficient in the bounding procedure. A promising avenue in this regard is to employ the so-called hybrid methods (i.e., combining exact methods and metaheuristics, see Jourdan et al. (2009) for a review). Unfeasible solutions. Most real-life scheduling models must deal with unfeasible solutions – in fact, the aim of scheduling is, in most cases, simply obtaining a feasible solution for the problem (Hopp and Spearman, 1996) –. While the performance of metaheuristics is extremely good for problems where the codification of the solutions does not lead to unfeasible solutions, this is not true for the case where such algorithms should handle unfeasible solutions. In contrast, specific algorithms for the model under consideration may yield very good (and feasible) solutions in a relatively shorttime period. Complementarities between generic and specific algorithms. For many cases, the performance of the generic algorithm heavily depends on the initial solution, usually provided by one or several specific algorithm(s). The Algorithm Library should give some hints regarding the selection of the algorithm. On one hand, it may be that the specific problem under consideration cannot be fit into the models that can be solved by the algorithms contained in the library. In this case,


the system should suggest/propose the usage of algorithms included in the library that can solve problems which are similar to the one under consideration. On the other hand, it may happen that more than one algorithm can be employed to solve a particular problem. From all these, the system should suggest/propose those more suitable on each case. Regarding the capacity of the systems to be enhanced with new algorithms, McKay et al. (2002) note that few systems contain libraries of configurable algorithms that plug and play. It has to be noted that the requirement is not only that completely new algorithms can be included in the library, but that existing algorithms can be tailored and that certain parts of these algorithms can be integrated into new ones. With respect to the extensibility of scheduling systems, also McKay et al. (2002) state that few systems allow the enhancement or combination of existing algorithms in a simple manner. For most commercial software either these algorithms cannot be enhanced or the procedure for their enhancement is extremely complex (Stadtler and Kilger, 2002). The blocks described in this section serve to implement many functionalities discussed in an earlier section. First, model detection functionalities (Section 3.2) can be implemented in the Preprocessor submodule although this requires intervention from the user interface module. Regarding to problem solving functionalities (Section 3.3), rescheduling algorithms are included into the Algorithm Library submodule together with scheduling algorithm (thus allowing multi-algorithm scheduling). An Algorithm Generator submodule is connected to the Algorithm Generator Interface (already discussed in Section 4.3) to facilitate the generation of new algorithms, which again requires a tight integration with the user interface. The Algorithm Library can also contain functionalities for the evaluation of algorithms. The only functionality presented in Section 3.3 and not included in our proposal is the incorporation of the human expertise, as their advantages are a subject of controversy. However, their integration in the proposed architecture is relatively straightforward. Finally, functionalities related to the evaluation of solutions for several objectives (discussed in Section 3.4) are covered by the Scheduler & Dispatcher submodule. Cleanly modularizing this part of the architecture is a challenging task as it is tempting to incorporate algorithm logic in other modules. However, abstraction and modularization is a must in order to avoid re-implementation of other modules at each implantation of a scheduling system.

5. Conclusions and future research In this paper, we have focused on an area that has received relatively little attention in the manufacturing scheduling field, at least as compared to the overwhelming wealth of literature dealing with scheduling models and procedures. However, in order to put these models and procedures into practice, they must adequately capture the details of a company’s manufacturing scheduling process, which usually entails modeling scenarios, constraints and objectives not often treated in the literature. In addition, the resulting models and solution procedures should be embedded into a manufacturing scheduling system that feeds them with reliable and timely data and provides an efficient way to interact with the users. This gives rise to a question on which the main blocks or components of a manufacturing scheduling system are and how they are related. Despite the specificity of scheduling systems, a number of features or functionalities can be identified, thus constituting the architecture of a manufacturing scheduling system. In order to analyse these functionalities, we have reviewed and classified existing contributions on the architecture of manufacturing scheduling systems, as well as works dealing with the description of a manufacturing scheduling system’s requirements. From this

245

analysis, we have proposed an integrated, modular architecture of scheduling systems covering all the so-identified functionalities. We do not claim that our proposal is the only way (or even the best way) to represent the architecture of a scheduling system, although it has been validated both through literature analysis and through industrial practice. By presenting it, we hope to enrich the rather scarce literature on the topic and thus help bridging the widely recognized gap between the development of scheduling models and procedures, and their implementation in a real-life industrial settings. We believe that the opinions raised in this paper may be highly influenced by the experiences of the authors, and that there may be complex, highly-constrained, non-repetitive scenarios in which the human expertise may outperform an automated manufacturing system, whereas an automated system could be preferable in other scenarios with a large number of different orders to be scheduled over a number of different machines on a repetitive basis. In any case, in our view, the automated system should serve to support the decisions of the human scheduler, and not to replace him/ her. In the proposed architecture, this idea is explicitly supported by stressing the need that the system should allow for the manual modification of the schedules, to manage different scenarios possibly with different objectives/constraints, or to include rescheduling algorithms, among other features. This area keeps open a number of extremely important issues for future research, most of which have been already mentioned through the paper. Among them, we would like to highlight the need to shift the research pattern in the scheduling field in order to increase the investigation on areas such as user interfaces, data management, scheduling monitoring, and, obviously, more tools and methods for a better design and implementation of manufacturing scheduling systems.

Acknowledgments The authors are thankful to the referees for their comments that have improved an earlier version of the paper. Jose M. Framinan is partly funded by the Spanish Ministry of Science and Innovation and by the Andalusian Government under grants DPI2007-61345 and P08-TEP-3630, respectively. Rubén Ruiz is partly funded by the Spanish Ministry of Science and Innovation, under the projects ‘‘SMPA – Advanced Parallel Multiobjective Sequencing: Practical and Theorerical Advances” with reference DPI2008-03511/DPI and ‘‘OACS – Advanced Optimization of the Supply Chain” with reference IAP-020100-2008-11.

References Aytug, H., Bhattacharyya, S., Koehler, G.J., Snowdon, J.L., 1994. A review of machine learning in scheduling. IIE Transactions on Engineering Management 41 (2), 165–171. Aytug, H., Lawley, M., McKay, K., Mohan, S., Uzsoy, R., 2005. Executing production schedules in the face of uncertainties: A review and some future directions. European Journal of Operational Research 161 (1), 86–110. Black, G., McKay, K., Morton, T., 2006. Aversion scheduling in the presence of risky jobs. European Journal of Operational Research 175 (1), 338–361. _ Błazewicz, J., Ecker, K., Pesch, E., Schmidt, G., Weßglarz, J., 2001. Scheduling Computer and Manufacturing Processes, second ed. Springer, Berlin. BPMG.org, 2004. Business Process Modeling Tools. . Brandimarte, P., Rigodanza, M., Roero, L., 2000. Conceptual modeling of an objectoriented scheduling architecture based on the shifting bottleneck procedure. IIE Transactions 32 (10), 921–929. Collinot, A., Le Pape, C., Pinoteau, G., 1988. Sonia: A knowledge-based scheduling system. Artificial Intelligence in Engineering 3 (2), 86–94. Dudek, R.A., Panwalkar, S.S., Smith, M.L., 1992. The lessons of flowshop scheduling research. Operations Research 40 (1), 7–13. Ecker, K., Gupta, J., Schmidt, G.A., 1997. framework for decision support systems for scheduling problems. European Journal of Operational Research 101 (3), 452– 462.

246


Ford, F.N., Bradbard, D.A., Ledbetter, W.N., Cox, J.F., 1987. Use of operations research in production management. Production and Inventory Management 28 (3), 59– 62. Fox, M.S., 1990. Constraint guided scheduling: A short history of research at CMU. Computers in Industry 14 (1–3), 79–88. Fox, M.S., 1994. Intelligent Scheduling, Chapter ISIS: A Retrospective. Morgan Kaufmann, pp. 3–28. Graves, S.C., 1981. A review of production scheduling. Operations Research 29 (4), 646–675. Gupta, J.N.D., Sexton, R.S., Tunc, E.A., 2000. Selecting scheduling heuristics using neural networks. INFORMS Journal on Computing 12 (2), 150–162. Hadavi, K., Shahraray, M., Voigt, K., 1990. ReDS – A dynamic planning, scheduling, and control system for manufacturing. Journal of Manufacturing Systems 9 (4), 332–344. Higgins, P.G., 1996. Interaction in hybrid intelligent scheduling. International Journal of Human Factors in Manufacturing 6 (3), 185–203. Hopp, W.J., Spearman, M.L., 1996. Factory Physics. Foundations of Manufacturing Management. Irwin, New York, USA. Huang, S.H., Zhang, H.-C., Smith, M.L., 1995. A progressive approach for the integration of process planning and scheduling. IIE Transactions 27 (4), :456– 464. Jacobson, I., Booch, G., Rumbaugh, J., 1999. The Unified Software Development Process. Jourdan, L., Basseur, M., Talbi, E.-G., 2009. Hybridizing exact methods and metaheuristics: A taxonomy. European Journal of Operational Research 199 (3), 620–629. Kanet, J.J., Adelsberger, H.H., 1987. Expert systems in production scheduling. European Journal of Operational Research 29 (1), 51–59. Kempf, K., 1994. Intelligent Scheduling, Chapter Intelligent Scheduling Semiconductor Wafer Fabrication. Morgan Kaufmann, pp. 517–544. Kirchmer, M., 1999. Business Process Oriented Implementation of Standard Software, second ed. Springer, Berlin. Kurbel, K., 2008. The Making of Information Systems. Springer. Lamatsch, A., Morlock, M., Neumann, K., Rubach, K., 1988. Schedule – An expert-like system for machine scheduling. Annals of Operations Research 16 (1–4), 425– 438. Lee, J., Lee, K., Park, H., Hong, J., Lee, J., 1997. Developing scheduling systems for daewoo shipbuilding: Das project. European Journal of Operational Research 97 (2), 380–395. Li, H., Li, Z., Li, L., Hu, B., 2000. A production rescheduling expert simulation system. European Journal of Operational Research 124 (2), 283–293. MacCarthy, B.L., Liu, J., 1993. Addressing the gap in scheduling research: A review of optimization and heuristic methods in production scheduling. International Journal of Production Research 31 (1), 59–79. Maturana, F., Gu, P., Naumann, A., Norrie, D.H., 1997. Object-oriented job-shop scheduling using genetic algorithms. Computers in Industry 32 (3), 281–294. McKay, K., Buzacott, J., 2000. Application of computerized production control systems in job shop environments. Computers in Industry 42 (2), 79–97. McKay, K., Wiers, V., 2003. Integrated decision support for planning, scheduling, and dispatching tasks in a focused factory. Computers in Industry 50 (1), 5–14. McKay, K.N., Pinedo, M.L., Webster, S., 2002. Practice-focused research issues for scheduling systems. Production and Operations Management 11 (2), 249–258. McKay, K.N., Safayeni, F.R., Buzacott, J.A., 1988. Job-shop scheduling theory: What is relevant? Interfaces 4 (18), :84–90. McKay, K.N., Safayeni, F.R., Buzacott, J.A., 1995. Common sense realities of planning and scheduling in printed circuit board production. International Journal of Production Research 33 (6), 1587–1603. McKay, K.N., Wiers, V.C.S., 1999. Unifying the theory and practice of production scheduling. Journal of Manufacturing Systems 18 (4), 241–255.

Numao, M., Morishita, S.A., 1989. Scheduling environment for steel-making processes. In: Proceedings of the Fifth Conference on Artificial Intelligence Applications, pp. 279–286. Olhager, J., Rapp, B., 1995. Operations research techniques in manufacturing planning and control systems. International Transactions in Operational Research 2 (1), 29–43. Pinedo, M.L., 2007. Planning and Scheduling in Manufacturing and Services, third ed. Springer, Berlin. Pinedo, M.L., 2008. Scheduling: Theory, Algorithms and Systems, third ed. Springer, Berlin. Pinedo, 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. Prietula, M., Hsu, W., Ow, P., Thompson, G.L., 1994. Intelligent Scheduling, Chapter MacMerl: Mixed-Initiative Scheduling with Coincident Problem Spaces. Morgan Kaufmann, pp. 655–682. Reinschmidt, K.F., Slate, J.H., Finn, G.A., 1990. Expert systems for plant scheduling using linear programming. In: Proceedings of the Fourth International Conference on Expert Systems in Production and Operations Management, Head Island, USA. Reisman, A., Kumar, A., Motwani, J., 1997. Flowshop scheduling/sequencing research: A statistical review of the literature, 1952–1994. IEEE Transactions on Engineering Management 44 (3), 316–329. Rossi, P., Diaz, C., Fruttero, P., Vittori, C., Rico, M., Chiotti, O., 1998. Decision support systems generator for industrial companies module iii: Scheduling support system. Computers & Industrial Engineering 35 (1–2), 311–314. Sauer, J., 1993. Meta-scheduling using dynamic scheduling knowledge. In: Dorn, J., Froeschl, K. (Eds.), Scheduling of Production Processes. Ellis Horwood, Upper Saddle River, NJ, pp. 151–162. Sauer, J., Apelrath, H.-J., 1997. Knowledge-based design of scheduling systems. In: Nahavandi, S., Saadat, M. (Eds.), Proceedings of WMC97 International Symposium on Manufacturing Systems, Auckland. Sauer, J., Bruns, R., 1997. Knowledge-based scheduling systems in industry and medicine. IEEE Expert, 24–31. Smith, S., 1994. Intelligent Scheduling, Chapter OPIS: A Methodology and Architecture. Morgan Kaufmann, pp. 29–66. Stadtler, H., Kilger, C., 2002. Supply Chain Management and Advanced Planning. Springer, Heildelberg. Steffen, M.S., 1986. A survey of artificial intelligence-based scheduling systems. In: Proceedings of the Fall Industrial Engineering Conference. T’kindt, V., Billaut, J.-C., Bouquard, J.-L., Lenté, C., Martineau, P., Néron, E., Proust, C., Tacquard, C., 2005. The e-OCEA project: Towards an internet decision system for scheduling problems. Decision Support Systems 40 (2), 329–337. Trentesaux, D., Moray, N., Tahon, C., 1998. Integration of the human operator into responsive discrete production management systems. European Journal of Operational Research 109 (2), 342–361. Yen, B.-C., Wu, O., 2004. Internet scheduling environment with market-driven agents. IEEE Transactions on Systems, Man and Cybernetics, Part A 34 (2), 281– 289. Yen, B.P.-C., 1997. Scheduling Description Languages. Technical Report, Department of Industrial Engineering and Engineering Management, Hong Kong University of Science and Technology, Hong Kong. Zentner, M.G., Elkamel, A., Pekny, J.F., Reklaitis, G.V., 1998. language for describing process scheduling problems. Computers and Chemical Engineering 22 (1–2), 125–145. Zhang, H.-C., Mallur, S., 1994. An integrated model of process planning and production scheduling. International Journal of Computer Integrated Manufacturing 7 (6), 356–364.