THE INTEGRATING ROLE OF SIMULATION IN MODERN MANUFACTURING PLANNING AND SCHEDULING

Slavko Arsovski1, Zora Arsovski2, Zoran Mirovic3

( Faculty of Mechanical Engineering, Kragujevac, Serbia, 2Faculty of Economic Science, Kragujevac, Serbia, 3Center for Qualty, Faculty of Mechanical Engineering, Kragujevac, Serbia) Abstract: The basic management problems in today's manufacturing organizations are integration of strategic and tactical decision making, developing the capability for plans and schedules reconfiguration and synchronization in a very short cycle as well as handling supply, operational and demand exceptions. This is reason why many firms have proceeded to the adoption of modern technological solution such as Enterprise Resource Planning (ERP) and Advanced Planning and Scheduling (APS) technologies. The final goal is a purposeful scheduling system that guide in the right direction the current, high priority needs of the shop floor while remaining consistent with long-term production plans. Simulations role in such a system is key due to its ability to faithfully replicate the real production ambiance and quickly react on unpredictable exceptions in the field. Its value is further enhanced when this solution is fully integrated with advanced planning function. It is apparent that there is a lack of a comprehensive, scientifically established design methodology to structure, guide, and improve manufacturing process modeling efforts. The approach presented in the paper gives verbal and mathematical problem description, builds ontology of problem domain, uses Extended Petri Nets and event graphs as activity cycle diagrams as modeling tools in order to obtain faithful model which easily can be replicated in object oriented class and object hierarchy. With proposed approach it is possible to focus, comprehensive but static ERP knowledge in dynamic simulation models and to fully utilize prediction power of simulation for effective and integrated strategic and tactical decision making. Key words: Manufacturing, Enterprise Resource Planning (ERP), Advanced Planning and Scheduling (APS), Discrete Event Simulation
1

1. Introduction
The speeding up of supply chain pace in which customer orders are initiated and finished products are delivered is one of the basic problems manufacturers must compete with and conquer. The most universal challenge is in handling supply, operational and demand exceptions what leads to the apparently impossible mission of planning for the unplanned. The speed at which business system identify these exceptions and react in order to reduce its negative impact on overall system performance primarily depends on responsiveness of enterprise information system and its capability of handling the above three factors. The contemporary solution is integration of strategic and tactical decision making and, on production level, developing the capability for synchronization, modification and fine-tuning of production plans and schedules as quick as possible. Today, business systems try to achieve this goal through implementation of modern information technologies, specifically, through integration of Enterprise Resource Planning (ERP), Advanced Planning and Scheduling (APS) and Discrete Event Simulation (DES) software systems [1]. Although an ideal ERP system should support the majority, if not all, of an enterprises business processes, in the production area and, more specifically, in the production planning and scheduling field, there was a lack of satisfactory support. Since 2000 many well known vendors of ERP systems such as SAP, Oracle, Baan, PeopleSoft and others have included in its commercial solutions, up to this moment relatively independent APS systems with scheduling and certain, limited simulation capabilities and have recorded

consistent growth in revenues [2]. Simulations scheduling role in such a system is key due in large part to its ability to faithfully replicate the real production ambiance and quickly react on unpredictable exceptions in the field. Its value is further enhanced when this solution is fully integrated with advanced planning function. Despite this fact, even now are evident problems in successful implementation and utilization of this scheduling, simulation supported solutions in everyday production practice. The main reason, what this paper suggests, is that in the domain of production scheduling it is not possible to design generic model (simulation software) capable to encompass all possible production system types and, in as much detail as it is necessary, all the subtleties of the concrete manufacturing environment. This is reason why above simulation solutions suffer the loss of its prediction power that is crucial for handling exceptions [4], [10], [11]. Simulation software systems are dynamic models of complex reality and this fact result in complexity of all stages of software creation. The paper also highlights unavoidability of knowledge transfer between three expert groups with different knowledge domains. First group are business processes experts, second software development experts and third from academic community research. Synthesis of mentioned fields of knowledge in proposed approach result in effective and functional simulation model. The paper suggests methodological design approach for Discrete Event Simulation software solution. Proposed approach gives verbal and mathematical problem description, builds ontology of problem domain, uses Extended Petri Nets and event graphs as activity cycle diagrams as modeling tools, in order to obtain faithful model which easily can be replicated in object oriented class and object hierarchy [5].

2. ERP, APS and DES in todays business

Enterprise Resource Planning (ERP) systems are software solutions that provide seamless integration of all enterprises business processes and information flows in the company attempting to synergize the resources of an organization. A typical ERP system is single software package that use multiple components of computer software and hardware to achieve mentioned integration. A distinctive constituents of most ERP systems is the use of a unified database, common data-processing and communications protocols to process and store data for the various system modules. ERP system combines all business applications together into a single, integrated software program that runs off a single database so that the various departments can more easily share information and communicate with each other. Ideally, ERP delivers a single database that contains all data for the software modules or business application, which would include: Manufacturing (Engineering, Bills of Material, Scheduling, Capacity, Workflow Management, Quality Control, Cost Management, Manufacturing Process, Manufacturing Projects, Manufacturing Flow), Supply Chain Management (Inventory, Order Entry, Purchasing, Product Configurator, Supply Chain Planning, Supplier Scheduling, Inspection of goods, Claim Processing, Commission Calculation), Financials (General Ledger, Cash Management, Accounts Payable, Accounts Receivable, Fixed Assets), Projects (Costing, Billing, Time and Expense, Activity Management), Human Resources (Human Resources, Payroll,

Training, Time & Attendance, Benefits), Customer Resources and Marketing (Sales and Marketing, Commissions, Service, Customer Contact and Call Center support) and various Self-Service interfaces for Customers, Suppliers, and Employees The largest vendors worldwide in 2005 according to Gartner Dataquest are: SAP (with revenue 4726 in million dollars and market share 28.7%), Oracle Applications (1674, 10.2%, The Sage Group (1221, 7.4%), Microsoft Dynamics (616, 3.7%), SSA Global Technologies (464, 2.8%). Planning and scheduling are closely related and are best done using the same or closely related tools like APS. Scheduling determines what is actually implemented in the process, while planning explores what is possible. Plans have little value if they are inaccurate and cannot be implemented because they do not consider important process requirements [6]. As such a contemporary APS system should support both planning and scheduling. With this in mind an APS system can be defined as computer software with ability to rapidly and simultaneously plan and schedule customer demand while considering material and capacity constraints as well as to reconfigure synchronized plans and schedules in a very short cycle time. The potential to increase business performance such as on-time delivery, shorter cycle times, reduction in inventories and increased throughput with APS is enormous. The available data suggests that the estimated improvement attributable to effective planning and scheduling is 5% to 15% as measured by a decrease in process costs (such as waste, changeover, inventory reduction) and/or increase in process throughput. In order to achieve this performance an APS system must be used in an effective business process whereby the data used is reasonably accurate and schedules and plans must be executed with reasonable precision. To achieve consistent results the planning and scheduling process must be repeated when business conditions change significantly. Low end APS systems cost on the order of several hundred or a thousand dollars. Midrange APS systems cost several tens of thousands of dollars to install. The most expensive APS systems generally cost about $500,000 to install, where half to two thirds of the cost is consulting fees to customize the system to a particular process. The purpose of an ERP is to provide data to those needing it therefore technical integration of APS systems with ERP data system is usually straightforward. Simulations scheduling role in such a APS system is key due in large part to its ability to faithfully replicate the real production ambiance and quickly react on unpredictable exceptions in the field. Its value is further enhanced when this solution is fully integrated with advanced planning function.

3. Planning and scheduling in ERP/APS ambiance

The computerized process of planning and scheduling in manufacturing have evolved from simplistic Material Requirements Planning systems to todays sophisticated Advanced Planning and Scheduling systems. While planning is concerned with the longrange determination of what needs to be manufactured, typically over a relatively long time period, scheduling is the task of deciding how that manufacturing is to be accomplished, usually over a relatively short time period. Simulation is well suited to the

scheduling task since it can handle as much detail as is necessary to capture the subtleties of the manufacturing process. It is desirable for a simulation-based scheduling function to be integrated with an Enterprise Resource Planning system, which maintains the system data suitable for driving a simulation of the current system load and thereby producing a feasible schedule. Modern Enterprise Resource Planning (ERP) systems contain all the data necessary for detailed production planning and scheduling. This includes product information, such as bills of material and routing of parts through the manufacturing process. It includes system information such as equipment, manpower, and shift schedules. It also includes status in formation such as the current order book, work in process, inventory levels, and released purchase orders. This is what is needed for an Advanced Planning and Scheduling (APS) function to determine how to efficiently plan a plants operations and to replan quickly and accurately based on changing requirements. The traditional Material Requirements Planning (MRP) computerized process in an ERP system concerns itself with determining the quantity of products to be made in a specified period of time. Initial information are demand for final products in that period, the component products which compose that demand, and the lead time required to produce each component and final product. A major defect in such an approach, of course, is that limits on manufacturing capacity are not considered [6]. Actual lead times usually vary considerably from the fixed lead times assumed by MRP when a system is highly utilized and dynamic. In order to determine whether or not an infinite capacity plan such as produced by MRP is actually feasible, simulation can be used to determine whether the start times generated by the plan will actually allow the manufacturing orders to be completed by their due dates. The integration of simulation with manufacturing planning systems became feasible in the 1980s as computing power increased to support production control systems, shop floor data collection systems and database management systems. While simulation is capable of producing a highly realistic manufacturing schedule, the task of correcting the infeasibilities of an MRP plan in capacity-constrained environments is quite discouraging. Through the years the authors have been involved in many successful applications of such, but the data requirements to maintain a realistic model consistent with the plan and the business process expertise needed to effectively execute it have made these successes costly and difficult to perpetuate. What is needed is a better starting point from which to schedule - which leads to APS systems. An APS system uses variants of the planning and scheduling approaches described above in an integrated way. A planner module which pays some attention to capacity constraints produces a schedulable plan. This plan then feeds a scheduler module, which produces a detailed list of operations showing how capacity will be used and returns this information to the planning function for use in the next planning period. The data regarding current and planned operations can also be used to provide realistic estimates of the ability to meet a new customer order request. Function of an APS system is to coordinate material and capacity planning in order to fulfill the demands being placed on the manufacturing system. It does this using three key processes: advanced planning, advanced scheduling, and order promising.

Figure 1. Traditional and Advanced Planning and Scheduling System The role of planning in APS is to determine what demands on the production system will be met over a given planning horizon. The input to the planning process includes information on manufacturing capacity and demand data. Demands may be of several types: customer orders, forecasts, transfer orders (i.e., orders from other plants), released jobs, or replenishments of safety stock. Manufacturing system data includes bills of material, work center availability, part routings through work centers, and inventory (both on-hand and scheduled for delivery). The output from the planning process is a feasible plan, which provides release and completion times for every demand. Like MRP before it, APS takes into account the availability of materials. Unlike MRP, it also takes into account the capacity of work centers to process the material and satisfy demands. This planning process is order-centric, focusing on the demand for end items and determining how much demand can be met in a given time period. Exactly how that demand will be met, in terms of specific assignments of jobs to work centers and their sequencing, is left to the scheduling function. It is in fact often desirable for a plan to be somewhat tentative, since it covers a planning horizon subject to disruptions. Forecasts may not be accurate. Deliveries may be delayed. Equipment may fail. Unexpected rush orders may be received. Therefore planning is not expected to be highly detailed. Individual machines may be aggregated into a work center with no determination of which will be used by a specific order. Setup times may be averaged since sequencing at this time is premature. Buffer times may be defined, especially prior to processing on bottleneck machines, to allow for possible disruptions. The end result is a schedulable plan. The logic of the planner algorithm operates on each order in turn, as follows [3]: Start backward from the promise date and reserve the work center capacity and material required for each operation. If the material required is a manufactured component, then it too is planned backward from the point at which it is required. If at the end of this pass the start date is on or after the beginning of the planning horizon, proceed to the next order. If the backward pass fails, meaning that the resulting start date would be in the past, reserve capacity and material forward from the planning start date. If the resulting completion date is within the planning horizon (even though after the promise date) this order is planned. If both the backward and forward passes fail, then the order is not included in the planning period. The end result of the above process is a feasible plan. The role of the scheduler module in APS is to produce a detailed list of operations specifying which orders are to be worked on at which work centers and at what times. The input to this module includes all demands to be satisfied, including the internal orders added by the planner module when an end item required a component to be manufactured. It includes the current material inventory levels as well as planned deliveries of purchased materials. It also includes the same manufacturing system data as that provided to the planner module but uses a more detailed representation of that data.

Detailed information used by the scheduler module that is not pertinent to the planner module includes: Variable run times based on the machine and operator actually assigned Rules for selecting machines and operators based on skill sets and quality requirements Variable setup times based on the previous and next part characteristics such as part type, family, color, width, etc. Rules for sequencing jobs at work centers, based on minimizing setup and other factors Acceptable shift overruns Rules for selecting from a list of prioritized jobs based on due date, slack, cost and other factors. The result is an accurate representation of what to expect on the shop floor in the immediate future. While the planner module typically considers demand on the system over a few weeks or months, the scheduler module will typically work with a much shorter time frame such as a shift, a day, or a week. The usefulness of a detailed schedule degenerates quickly as time passes, since disruptions on the shop floor or changes to the order mix may require significant adjustments. For this reason a simulation used for generating a schedule is usually deterministic. If a random event occurs (i.e., machine failure, arrival of a rush order, or a missed delivery date by a supplier) then a new schedule can quickly be generated and its impact evaluated. 3.1 Scheduling Using Simulation While the APS planning function is order-centric, the APS scheduling function is eventdriven. Given a set of orders and associated start dates, the scheduler algorithm begins by generating a calendar, that is, a time-ordered list containing the first scheduled operation for each order. As each operation is able to acquire the work center capacity and materials it requires, the calendar is updated to reflect the time at which the operation will end. Each order moves through its route over time, with its completion date dependent on the dynamics of the system. Which specific machine will it be allocated at a given operation? How long will it have to wait for other orders at the same machine? What will the setup time be? Answers to these questions cannot be planned ahead of time, but rather unfold dynamically as orders move through the system over time. The end result is a detailed schedule. Figure 3 illustrates that the scheduled jobs dictated by the scheduler module and purchase orders released by the ERP system are returned to the planner module for the next planning run. It is this put back. that allows the APS Planner to continue to produce realistic plans while honoring the APS schedules. The entire planning and scheduling process is tightly integrated, but not automatic. As described earlier, the APS Planner produces planned manufacturing orders and planned purchase orders. Figure 2: Closing the Planner/Scheduler Loop with Simulation These are based on actual customer orders and, optionally, on forecasts and other estimates. A (human) production planner now may use these recommendations to release

jobs to the shop floor and to create purchase orders. The APS Scheduler is then run, and uses these planned and released jobs to assign work center capacity and inventory. Only the released job assignments are then fixed within the APS Planner to create new recommended plans. A feasible schedule may not be a desirable schedule. If too many orders are not schedulable, for example, there are a number of things that might be tried to temporarily in crease the capacity of the system. Perhaps an extra shift could be added for a key work center. Temporary help might be brought in if labor is the bottleneck. One or more operations might be outsourced. A major benefit of simulation has always been the ability to investigate variations on a system without disturbing its operation. This benefit has been brought to APS by providing the ability to copy the ERP data and experiment with changing one or more parameters and comparing the results with the original. The ability of an APS system to realistically project order completion times as well as the utilization of capacity and materials is critical in todays competitive manufacturing world. Combining APS planning technology with enterprise management processes can improve customer service and on-time delivery, reduce expediting, overtime and inventory, and increase throughput and profit. Simulations scheduling role in such a system is key due in large part to its ability to faithfully replicate the real world. Its value is further enhanced when fully integrated with advanced planning and order promising.

4. Proposed design methodology and review of concrete solutions

Simulation software systems attempt to model or replicate complexity of real systems what result in complexity at analytical, design and technological level of software creation. This is reason why effective modeling is one of the most important and difficult steps in the development of reliable simulation software systems. At this point, the paper highlights inevitability of knowledge transfer between three knowledge domains [9], [10]. First domain is knowledge about the business processes, second knowledge about software development and implementation and third from academic community research (Operational Research and Management Science) about problem domain. Integration and overlapping of mentioned specialized fields of knowledge for the solution of the common task result in useful and functional simulation model. In this framework the paper propose methodological design approach for Discrete Event Simulation solution (Figure 3.). This approach gives verbal and mathematical problem description, builds ontology of problem domain, uses Extended Petri Nets and event graphs as activity cycle diagrams as modeling tools, in order to obtain faithful model which easily can be replicated in object oriented class and object hierarchy. Figure 3: Proposed methodology 4.1 Basic concepts Production scheduling is defined as a process of realistically synchronizing the use of resources by activities to satisfy orders over time. An order is an input request for one or more products, which designate the goods or services required. Satisfaction of orders centers around the execution of activities. An activity is a process that uses resources to produce goods or provide services. The use of resources and the implementation of

activities is restricted by a set of constraints. These five basic ontology order, activity, resource, product and constraint together with the inter-relationships define an abstract model of a production scheduling domain. Of course, there are many other ontology necessary for the successful design of a production scheduling information system[7]. In the following subsections, we analyze the basic ontology of the methodology in more detail. Order Concept definition. An order is a specific request for goods and/or services, or more generally products, which the system being modeled can produce. Orders specify the input goals that drive the system, along with any constraints that should be taken into consideration when achieving them. Properties. An order has several defining properties: Order_code. Every order is inserted in the production scheduling system through a specific string code. Product_code. Every order concerns the production and delivery of one specific product which is characterized by a specific code as well. Quantity. A parameter relating to the size of the order (e.g. the number of products requested). Due_date. This date represents the committed shipping or completion date (the date the job is promised to the customer). The completion of a job/order after its due date is allowed, but a penalty is incurred. When the due date absolutely must be met, it is referred as a deadline. Priority. The relative importance/weight of the order which may concern the customer, the requested quantity, the inventory cost, etc. The relative value of the priority may result from a complex formula, combining a lot of factors. Order_status. A parameter indicating the current status of a specific order: scheduled, in-process, completed. Product Concept definition. A product is a good realized through the execution of some set of activities. An order for a product is considered satisfied when all of these activities have been completed. Properties. The product definition includes the following: Product_code. Every product is recognized by the production scheduling system through a specific string code. Routing_code. Each product has a fully defined way of its production (routing), which is described by a specific and unique sequence of activities. Each product has its own routing which is characterized by a specific code. Routing

Concept definition. The routing indicates the specific set of activities which must be implemented so that a product is produced, as well as their sequence. Properties. The routing definition includes the following: Routing_code. This code is unique for the production of a specific product. Activity_code. Each activity which should be executed has its own code. Activity_range. The range on the basis of which an activity must take place. Activity Concept definition. An activity represents a process that can be executed over a certain tine interval. An activity requires resources to be executed and its execution both depends on and affects the current state of these resources. Properties. The action of scheduling an activity involves the determination of values of certain variables. The basic decision variables associated with an activity are: Activity_code. Each activity which can be executed has its own code. Product_code. This code must be known since an activity may concern various products. Start_time. The time (or date) at which a specific activity begins to be implemented. End_time. The time (or date) at which a specific activity is completed. Workcenter_code. A specific work center undertakes to execute an activity. Each work center is characterized by a string code. A work center may be a single machine or a group of similar machines which deal with a specific work. Activity_range. The range on the basis of which an activity will take place is defined by the specific routing. Activity_status. An activity may be in one of the following states: unscheduled, scheduled, in-process, completed. Resources Concept definition. Central to the definition of our scheduling ontology is the concept of a resource. A resource is an entity that supports or enables the execution of activities. Resources are generally in finite supply and their availability constrains when and how activities can be implemented. In a manufacturing system, a resource can be a machine (or a work center in general) and/or human resource needed for the proper execution of an activity. In general, we can distinguish two broad classes of resources from the standpoint of availability: Capacitated-resources, whose availability is characterized in terms of the amount of capacity that is available. Discrete-state-resources, whose availability is a function of some discrete set of possible state values.

It is stressed that the resources, together with their properties (machine_capacity, machine_code, technician_code, etc.) are embodied in the other basic ontologies. Work center Concept definition. A work center is an area in a business in which productive resources are organised to implement a specific work. A work center may be a single machine or a group of similar machines. These work centers can be organised according to functions in a job-shop configuration, or by product in a flow-shop (assembly line). Properties. The work center definition includes the following: Workcenter_code. A specific work center undertakes to execute an activity. Each work center is characterized by a string code. Activity_code. Each work center implements a specific activity. Average_setup_time. The setup time specifies how long it takes for a machine to be prepared for use by an activity. The average setup time is used when a work center contains a lot of machines (more than 30). In this occasion the work center is modeled as a single machine with an average setup time. Average_capacity. The average capacity is used when a work center contains a lot of machines (more than 30). In this occasion the work center is modeled as a single machine with an average capacity. Machine Concept definition. A machine is considered to execute only one activity every time and it is specified by the scheduling system. Properties. The properties of a machine are the following: Machine_code. Every machine is characterized by a unique string code. Workcenter_code. Every machine belongs to a specific work center. Machine_capacity. Every machine has its own capacity (ranging between minmax values). The role of this parameter is very crucial for the optimization of the schedules provided by the information system. Machine_availability. This changeable parameter indicates whether a machine is available or is currently used by an activity. The potential states may be 1 or 0 respectively. Machine_flag. This parameter indicates whether a machine is under repair or maintenance or it works properly. The potential states may be 0 or 1 respectively. Personnel Concept definition. An activity can be executed by using machines and human resources (personnel) as well. The human resources concern both the necessary setup of a machine and the whole execution of an activity. Properties. The properties of personnel are the following:

 Technician_code. Each technician has his own code which characterizes him/her in the scheduling system. Product_code. This code must be known since an activity may concern various products. Activity_code. This parameter in combination with the product_code indicates the work (kind, input, etc.) a technician should do. Machine_code. This code indicates the scheduled machine in which a technician will work in order to implement a specific activity. Setup_input. This is the input provided by a technician for the setup of a machine. This parameter will be calculated by the system, taking into consideration the product, the activity and the selected machine. Activity_input. This is the input provided by a technician for the proper implementation of an activity. This parameter will be calculated by the system, taking into consideration the product, the activity and the selected machine. Constraints Concept definition. Generally speaking, a constraint restricts the set of values that can be assigned to a variable. In the production scheduling domain, constraints restrict the assignment of start and end-times and the allocation of resources to activities. Properties. From this perspective, we can identify two basic types: Hard. The production scheduling system is never allowed to violate hardconstraints. Soft. Alternatively, soft-constraints are considered to be relaxable, if needed so. For example, due-date constraints are treated as relaxable constraints in many scheduling systems. Possible restrictions and constraints which may appear in a production scheduling system are the following: Release dates. A specific job may not start its processing before its release date. Preemptions. Preemptions imply that it is not necessary to keep a job on a machine until completion. The scheduler may interrupt the processing of a job (preempt) at any time and put a different job on the machine. The amount of processing a preempted job has already received is not lost. When a preempted job is put back on the machine (or on another machine), it only needs the machine for its remaining processing time. Precedence constraints. Precedence constraints may appear in single machine or in parallel machine environments, requiring that one or more jobs may have to be completed before another job is allowed to start its processing. Permutation. A constraint that may appear in the flow-shop environment is that the queues in front of each machine operate according to the FIFO discipline. This implies that the order in which the jobs go through the first machine is maintained throughout the system.

 Blocking. Blocking is a phenomenon that may occur in flow-shops. If a flow-shop has a limited buffer in between two successive machines, the upstream machine is not allowed to release a completed job. Recirculation. Recirculation may occur in job-shops, when a job may visit a machine more than once. 4.2 Mathematical specification A scheduling task can be formally represented as a mapping from a nine-dimensional space {J, A, R, C, Req, Tr, P, Cf, Cr} to a set of schedules S = {S1,., Sn}. These parameters are described as follows: Job, J = {j1, ., jm}. A set of jobs to be assigned to a set of resources for their execution. Activities, A = {a1, ., an}. A set of activities. Each activity must be associated to a job, and no activity can be associated to more than one job. Resources, R = {r1, ., ri}. A set of resources to which the jobs can be assigned for their execution. Constraints, C = {c1, ., cj}. A set of constraints that must not be violated by a solution schedule. Requirements, Req = {req1, ., reqk}. A set of requirements that describe the desired properties of a solution schedule. Schedule time range, Tr. The time horizon in which the schedule takes place. Preferences, P = {p1, ., pt}. A set of criteria for choosing among competing solution schedules. Each preference defines a partial order over the set of solution schedules. Cost function, Cf. A function, which computes the cost of a final solution schedule. Solution criterion, Cr. A mapping from S to {True, False}, which determines whether a candidate schedule is a solution. The minimal set of conditions imposed by a solution criterion on a solution schedule, say Si, normally requires Si to be correct, complete, admissible, and feasible - see below for the definitions of these properties. More restrictive solution criteria may introduce optimality conditions based on the applicable preferences and cost function. Schedule, S = {<ji, aij, rk, trijk>}. A schedule is a set of quadruples <ji, aij, rk, trijk >, where ji is a job, aij is an activity associated with ji, rk is a resource, and trijk is the job time range assigned to activity aij of ji. A job time range specifies the earliest and latest start time and the duration of aij. We assume that no additional control information is required to interpret a schedule. In other words, we assume that the execution of a schedule only requires assigning resources to jobs and activities, in accordance with the given time ranges. Criteria to check the validity of a schedule.

 A schedule, say Si, is correct, if no pair <ji, aij> appears in more than one quadruple in Si. A schedule, say Si, is complete, if for each activity aij in A, associated with job ji, there exists a quadruple q in Si, such that q = <ji, aij, rk, trijk >. A schedule, say Si, is admissible, if it does not violate any of the applicable constraints. A schedule, say Si, is feasible, if it satisfies all requirements in Req. A solution schedule, say Sopt, is optimal, if there is no other solution schedule that has a lower cost than that of Sopt. This approach uses Extended Petri Nets (EPN) like graphical and mathematical modeling tools that can be used to perform static and dynamic modeling of existing manufacturing systems. Manufacturing systems are characterized as being concurrent, asynchronous, distributed, parallel, non-deterministic, and stochastic and can be effectively modeled and analyzed by using Petri Nets. A placedenoted by a circlerepresents a condition such as input data, input signal, resource, condition, or buffer. A transitiondenoted by a solid bar represents an event such as a computation step, task, or activity. Arcs are utilized to connect places and transitions in a Petri Net. Arcs are directed (depicted by arrows) and are either drawn from a place to a transition or from a transition to a place. Arcs in a Petri Net have multiplicity. The fourth element called the token and denoted by a solid circle provides the dynamic simulation capabilities to Petri Nets. Tokens are initialized at a place and a place may contain zero or more tokens. With the use of tokens the modeler can provide the necessary dynamic links between the places (conditions) and transitions (tasks or events) in a Petri Net. The concept of transition firing allows a Petri Net to simulate the dynamic behavior of a system. In their original form transition firing in Petri Nets was instantaneous. but, time is incorporated into Extended Petri Nets. This results in a timed transition that will have the ability to model tasks or activities.
Figure 4: EPN symbols

Figure 5: Activity Cycle diagrams

4.3 Review of concrete solutions Ontology concepts are the base for object oriented class and object hierarchy design and EPN approach helps modeling of manufacturing system and software system dynamics. Realized simulation tool has a number of unique characteristics such as interactive Gantt chart display, specialized reports, integration with external data sources, specialized scheduling rules, concurrent graphical animation etc. The quality of the generated schedule is largely determined by the scheduling rules that are specified for selecting resources and operations. A complete set of rules must be incorporated into the simulation tool to support a specific range of given manufacturing identity. Figures 6 to 7 presents screens of simulation solutions developed for different manufacturing environments.

Figure 6. Concurrent graphical animation Figure 7. Gantt chart

Figure 6 depicts a screen with concurrent graphical animation of flexible manufacturing system shop floor with four machines. Simulation software enables visual presentations to the user of all system events in corresponding time interval. Figure 7 presents Gantt diagram depicting complete system behavior with machine utilization and maximum flow time of job orders realization. Implementation of realized software solutions can accelerate the flow of the right information, quality and speed of decision making what results in increasing of overall system performance.

5. CONCLUSIONS
A dynamic simulation-based approach to production planning and scheduling has distinct advantages over commonly used static approaches [7], [12]. The most vital of these is the direct and dynamic link to the shop floor. Simulation has the ability to accurately model detailed system operating rules and evaluate them over time what is invaluable in ensuring that a plan or schedule is feasible on the shop floor level. Sudden changes in employee availability, machine breakdown, extra orders, order expediting requirements, etc. can be reacted to quickly using simulation to generate a new and efficient schedule within minutes. It is difficult to assess the feasibility of schedules generated by static methods other than by actually executing it in real time on the shop floor. This limits the opportunity to anticipate inefficient or unfeasible plans in advance. Solutions can be fully customized according to the current planning and scheduling rules and incorporated in modern ERP/APS environment. Integration of planning and scheduling with simulation bridge the gap between tactical and strategic management information systems resulting in a more coordinated production planning and execution.

REFERENCES [1] Musselman, K.J., and Uzsoy, R., Advanced planning and scheduling for manufacturing. In G. Salvendy, Handbook of Industrial Engineering (3rd ed.). 2001, New York. [2] Metaxiotis, K.S, Psarras J.E, Ergazakis, K.A, Production scheduling in ERP systems: An AI-based approach to face the gap, Business Process Management Journal, Volume 9 Number 2, 2003 pp. 221-247 [3] Arsovski Z , Decision Support Systems in CIM System Development, CIM center, Mechanical Faculty, University of Kragujevac, 1998. [4] Mirovic Z, Quality through Integration of Production and Shop Floor Management by Discrete Event Simulation, 2nd International Quality Conference, Kragujevac, 2007 [5] Arsovski Z., Arsovski S., Mirovic Z., Integration of Just In Time and MPII concepts by simulation software, INFOFEST '98, Budva, 1998, [6] Mirovic Z, Modeling Flexible Manufacturing Systems, Master Thesis, University of Kragujevac, Mechanical Faculty, 1996 [7] Smith, S. F.; Becker, M. A. An Ontology for Constructing Scheduling Systems. Proceeding of AAAI-97, Spring Symposium on Ontological Engineering, 1997.

[8] Arsovski S., Stefanovic M., Virtual Factory and Virtual Quality, Total Quality Management Advanced and Intelligent Approaches, 2003, pp. 117-120. [9] Stefanovic N., Arsovski S., Quality Aspect of Supply Chain Management, Total Quality Management Advanced and Intelligent Approaches, 2003, pp. 81-85. [10] Stefanovic N., Arsovski S., Supply Chain Management in Digital Factory, The 36th CIRP International Seminar on Manufacturing Systems, 2003. [11] Arsovski Z., Arsovski S., Punosevac Z., Integration of Quality Support with Information Communication Technology (ICT) into Business Strategy, 15th International Conference on Management of Technology (IAMOT), China 2006. [12] Arsovski Z., Arsovski S., Stefanovic M., A New Approach to Managing Application Development from Aspects of Quality, 1th International Quality Conference, Kragujevac, 2006.
Authors Addresses: Slavko Arsovski Faculty of Mechanical Engineering 34000 Kragujevac, Serbia [email protected] Zora Arsovski Faculty of Economic Science 34000 Kragujevac, Serbia [email protected] Zoran Mirovic Center for Quality Faculty of Mechanical Engineering 34000 Kragujevac, Serbia [email protected]