Transition net

Available online at www.sciencedirect.com

Expert Systems with Applications Expert Systems with Applications 35 (2008) 1841–1857 www.elsevier.com/locate/eswa

Systematic modeling and implementation of a resource planning system for virtual enterprise by Predicate/Transition net Hsien-Pin Hsu a

a,*

, Hsien-Ming Hsu

b

Department of Logistics Management, National Kaohsiung Marine University, Kaohsiung, Taiwan b Department of Information Management, National Taiwan University, Taipei, Taiwan

Abstract While fierce competition impels many of the commercial markets into a low-profit environment, virtual enterprise (VE) appears as a business strategy for small and medium-sized enterprises (SMEs) to alley together. However, to support the operations of a VE, a resource planning system (RPS) is required. In this study, a systematic and hierarchical approach which consists of top-down modeling and bottom-up implementation steps is proposed and used for developing the RPS. Following this approach, a Predicate/Transition (Pr/ Tr) net model for resource planning is derived. In addition, activity-based costing (ABC) is applied to provide a financial measure, profit, which is believed to be more meaningful in a collaborative environment. The Pr/Tr net model is further transformed into Horn clauses, and implemented by a logical programming language, Visual Prolog. Finally, a RPS which contains graphical user interface, model and knowledge database is developed. In the RPS, the goals and dispatching rules can be easily included and evaluated. In addition, the schedules based on the best dispatching rule can be generated. An example of horizontal collaborative manufacturing is used to illustrate the application of the RPS and the generation of the schedules.  2007 Elsevier Ltd. All rights reserved. Keywords: Resource planning system; Virtual enterprise; Predicate/Transition net; Activity-based costing; Horn clause

1. Introduction Many of today’s commercial markets are increasingly moving toward a low-profit environment, as a result it is hard for an independent firm to survive, especially those of small and medium-sized enterprises (SMEs). Usually, a SME is difficult to compete with a big one thus applying business strategies is sometimes crucial. Among the strategies, forming a virtual enterprise (VE) is recognized as one that may improve the competitive advantages of the participants, hence it becomes important. In an allied environment, VE is usually formed by distributed partners (or participants) and conceptually entitled by a nominal name so that a dedicated organization is not necessary. However, to realize the benefit of a VE, coordinating the participants’ *

Corresponding author. Tel.: +886 7 3617141 3464; fax: +886 7 3617141 3451. E-mail address: [email protected] (H.-P. Hsu). 0957-4174/$ - see front matter  2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.eswa.2007.08.082

resources is critical. This implies that a Resource Planning System (RPS) is required. Two aspects are important to develop a RPS for VE: the collaboration type and the approach. The collaboration type relates to the scope and functions the RPS is going to support while the approach relates to the model and procedure used to develop the RPS. Basically, three types of collaborations (horizontal, vertical and lateral collaborations) can be applied. However, to apply the collaborations, the features of each type must be first investigated and the RPS can then be developed properly. Definitely, a RPS can be designed and developed to support multiple collaborations simultaneously. In past research, Koestler (1989) introduced a theoretical framework for autonomous and decentralized manufacturing based on classical holonic paradigm; Huang and Leachman (1996) proposed a framework for VE control. In addition, Mezgar, Kovacs, and Paganelli (2000) proposed a co-operative manufacturing network model to coordinate the production of SMEs.

1842

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

Moreover, Huang, Hu, and Li (2004) applied timed colored Petri Net (TCPN) to model distributed manufacturing processes of member enterprise of a virtual manufacturing organization (VMO). However, these researches mainly focused on the modeling phase thus the implementation phase was not detailed; still there is a gap between the modeling and implementation phases. Thus, a procedure which can systematically support and closely link both of the modeling and implementation phases is required. In addition to the procedure, modeling tool is another critical factor impacting the development of a RPS. In this study, Predicate/Transition (Pr/Tr) net is selected as the modeling tool due to its powerful modeling capability supported by two important features emphasized by Janneck and Naedele (1998): the ability of abstraction and refinement as well as the ability of configuration support. The former provides basic functions for modeling a system while the later enables system variants to be included flexibly. Moreover, Pr/Tr nets represent knowledge and reasoning rules (by predicates and transitions) graphically, thus they can be easily transformed into Horn clauses. Additionally, along with some other (expert) knowledge, a (expert) knowledge-based planning engine of the RPS can be established. In the past, it is found that dispatching rules have been widely used for planning, and non-financial measures (such as maximum throughput, maximum utilization of workstations, minimum production cycle time, least tardiness or maximum wafer movements) have been used to evaluate the planning results (Glassey & Resende, 1988; Johri, 1993; Spearman, Woodruff, & Hopp, 1990; Uzsoy & Lee, 1992; Wein, 1988). Non-financial measures, however, cannot dollarize the amount of improvement (Fisher, 1992), nor can they directly link to an enterprise’s financial vision, such as a company-level profitability, which is much emphasized by small firms (Laitinen, 2002). Fortunately, activity-based costing (ABC) was found can cover the shortages. ABC was firstly introduced by George and Stabus in 1977 and was believed can provide visibility to cost behavior (Ong, 1995; Pirttila & Hautaniemi, 1995). Moreover, ABC was further suggested could be adapted to provide profit information (Salafatinos, 1996), a financial measure, which is believed to be more meaningful in a collaborative environment because it seems hard to sustain a partnership without a profitable foundation. Thus, this study includes cost/profit concept into the RPS, differing to most of the past research. This study aims to propose a systematic approach which can be used to develop a RPS for VEs to operate in a collaborative environment. This paper is organized as follows. The types of collaborations, ABC, Pr/Tr net, Horn clauses and Prolog program are reviewed in Section 2. The modeling of the RPS by Pr/Tr net is conducted in Section 3. The implementation of the RPS is conducted in Section 4. An example used to illustrate the application of the RPS is presented in Section 5. Finally, conclusion and future research direction are presented in Section 6.

2. Literature review 2.1. Collaborative environment and types of collaborations Xu, Ye, and Li (2005) regards the VE as a dynamic alliance, which integrates the resources from one/many real enterprise through information infrastructure to respond rapidly to business opportunity. Fig. 1 illustrates a collaborative environment, in which a VE is formed to accept orders and coordinate the operations of the participants (companies A, B and C). Before start planning, the information of available resources are forwarded to the VE by the participants via the Internet. Thereafter, a RPS is used to plan and create the schedules that are further sent back to the participants for manufacturing. By the Internet, the visibility on the available resources of the participants can be easily enhanced; this facilitates the resource planning and cooperation of the participants. Basically, there are three types of collaborations: the horizontal, vertical and lateral collaborations (Togar & Sridharan, 2002). The type of collaboration is mainly decided by the collaboration scenario and the attributes of the participants. Each type of collaborations is defined below: • Horizontal collaboration: occurs when two or more unrelated or competing organizations cooperate to share their private information or resources, such as joint distribution centers. • Vertical collaboration: occurs when two or more organizations such as the manufacturer, the distributor, the carrier and the retailer share their responsibilities, resources, and performance information to serve relatively similar end customer. • Lateral collaboration: aims to gain more flexibility by combining and sharing capabilities in both vertical and horizontal manners. 2.2. ABC Basically, ABC model describes product (cost object) consumes activities and activities consume resources, therefore from the two stage the product cost can be derived. Cooper and Kaplan (1988) categorized costs into unitlevel, batch-level, product-level and facility-level cost, each of them is further detailed: • Cost object: an object that consumes activities, such as product or order. Costs of the consumed activities can be rolled up to the object. • Cost driver: the factors incur costs for a specific activity, such as process time, quantity of product, or quantity of material consumed. • Unit-level cost: is defined as inputs increase in proportion to the number of units processed, such as number of wafers to be grinded, etc. Most of the activities occurred on the production line can be attributed to unit-level cost.

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

1843

Fig. 1. Collaborative environment linked by Internet.

• Batch-level cost: assume that inputs vary in proportion to the number of batches processed, such as set-up required whenever a batch of product is to be manufactured. • Product-level cost: assume that inputs are necessary to support the manufacturing of each different type of product, such as inventory holding for all completed products. • Facility-level cost: is those costs related to sustaining a facility’s general manufacturing process, such as a general administrative cost. Based on the ABC, costs can be finally rolled up to the cost object. Thus, the total profit can be calculated if the sale prices of the cost objects are available. 2.3. Predicate/Transition net Predicate/Transition (Pr/Tr) net is a directed graph. Formally, A Pr/Tr net consists of the following constituents (Genrich & Lautenbach, 1986):

(4) An inscription on some transitions being a logical formula built from the operations and relations of the structure R; Variables occurring free in a formula have to occur at an adjacent arc. (5) A marking M of predicates of P with formal sums of n-topples of individual symbols. (6) Firing rule: Each element of T represents a class of possible changes of markings. Such a change, also called transition firing, consists of removing tokens from a subset of predicates and adding them to other subsets according to the expressions labeling the arcs. A transition is enabled whenever, given an assignment of individual tokens to the variables that satisfies the predicate associated with the transition. In a Pr/Tr net, predicates are used to model states, transitions are used to transit the states, and tokens are used to mark a set of states. Fig. 2a illustrates a Pr/Tr net where W, R, U, V are predicates, t is a transition, Y < Z is a logical formula of t, hX, Yi, hZi, hXi + hY, Zi are labels of formal sum constructed by token variables (X, Y, Z), and ha, bi, hci are tokens reside at W, R predicates, respectively.

(1) A directed graph (P, T, A) where P is the set of predicates (‘first-order’ places), T is the set of transitions, A is the set of arcs. (2) A structure R consisting of some sorts of individual tokens (Pi) together with some operations (OPj) and relations (Rk), i.e. R ¼ ðP 1 ; . . . ; P i ; OP 1 ; . . . ; OP j ; R1 ; . . . ; Rk Þ: (3) A labeling of all arcs with a formal sum of n attributes of token variables (including the zero-attributes indicating a no-argument token).

Fig. 2a. A Pr/Tr net example.

1844

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

fact (1), fact (2) and rule (4) can formulate a specific theory (assume theory1). The purpose of the theory is to answer questions, such as ‘‘who is the grandfather of Bill?’’. The question can be represented as a goal clause ?-grandFatherðPerson; GrandFatherÞ

ð5Þ

An answer resulted from the query is called a solution. Sometimes, no solution or more than one solution is possible. Fig. 2b. The Pr/Tr net after t is fired.

Meanwhile, the transition t is enabled (friable), and Fig. 2a becomes to Fig. 2b, after transition t is fired. More details of the definition and properties of the Pr/Tr net are available in (Genrich, 1987; Giordana & Saitta, 1985; Murata & Zhang, 1988; Murata, 1989). In addition, some other application researches are available in (Hsu, Chen, & Su, 2004; Hsu & Su, 2005; Yan, Wang, Zhang, & Cui, 1998). 2.4. Horn clause logic and prolog program 2.4.1. Horn clause logic Pr/Tr net is useful in solving practical problem, such as Horn clause logic programs (Chow & Li, 1997; Peterka & Murata, 1989). Horn Clause logic is a formal system for reasoning about things and the way they relate to each other. A Horn clause is a clause constructed by one or more predicates. Predicates can be regarded as functions whose domain is the set of {true, false}. A Horn clause formed by one predicate is called one predicate Horn clause, or fact. Such as fatherð\Bill"; \John"Þ;

ð1Þ

fatherð\John"; \Pam"Þ

ð2Þ

are facts. Fact (1) can be interpreted as ‘‘John is the father of Bill’’. In the clause, father is the name of the predicate while ‘‘John’’ and ‘‘Bill’’ are attributes. A Horn clause containing more than one predicate usually appears as the form of a rule H : - T 1; T 2; . . . ; T n;

ð3Þ

where Ti and H are predicates, the symbol ‘‘:-’’ represents an implication that means if, and a comma separating two predicates represents the relation and. Therefore, the rule (3) implies ‘‘H is true if T1 and T2. . . and T n are true, false otherwise’’. Statements like ‘‘X is the grandfather of Z, if X is the father of Y and Y is the father of Z’’ can be transformed into the following rule by Horn clauses: grandFatherðPerson; GrandFatherÞ : - fatherðPerson; FatherÞ; fatherðFather; GrandFatherÞ; ð4Þ where Person, Father, GrandFather are variables (with upper case in the first letter) used to represent Z, Y, X, respectively. A theory is a collection of facts and rules. With facts and rules, we can formulate theories. For instance,

2.4.2. Prolog program A Prolog program contains theory and goal. For instance, together the theory1 with the goal clause (5) we can form a Prolog program (assumed P1). When the program starts it tries to find a solution (or solutions) of the goal in the theory. In a rule, the part before the symbol ‘‘:-’’ is called the head while the part after the symbol ‘‘:-’’ is called the tail of the rule. The process of reasoning a rule starts from the first predicate of the tail and then the second one, etc. Precisely speaking, the Prolog program adopts a Depth First Search (DFS) algorithm. Thus, to solve the goal clause grandFather(Person, GrandFather), rule (4) will be called and then the first predicate, father(Person, Father), will be first solved and then followed by the second predicate father(Father, GrandFather). During the reasoning process, the variables of the predicate will be bound with the values of the attributes of a fact; the process is called unification. When more than one fact of a same predicate appear in a program, such as fact (1) and fact (2), then the most top one will be bound firstly and then followed by the next one; i.e. by a top to bottom sequence. Based on the DFS algorithm and top to bottom sequence, the solution grandFather(‘‘Bill’’, ‘‘Pam’’) which indicates that ‘‘Pam is the grandfather of Bill’’ will be resulted from the Prolog program P1. More than one clause can be used to define a rule. Such as rule (3) and rule (6) are simultaneously used to define the H predicate. In such a case, the DFS algorithm is also applicable. H : - K 1; K 2; . . . ; K m:

ð6Þ

3. Modeling A two-stage approach is used to model the RPS; stage (1) develop the top-level Pr/Tr net model, and stage (2) refine the top-level Pr/Tr net model. 3.1. Develop the top-level Pr/Tr net model Resource planning can be regarded as a process to assign tasks Ti to resources Rj iteratively until all the tasks are completed under imposed constraints (Schmidt, 1996). Accordingly, two predicates (tasks and resources) and one transition (assign) are used to simulate the assignment scenario and a top-level (Level 0) model is then formed in Fig. 3a where some components are constructed by dotted

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

1845

Fig. 3a. Pr/Tr net model of resource planning (Level 0).

lines implying that the components (or the net) are not at the lowest-level. In this case, further refinements are required. 3.2. Refine the top-level Pr/Tr net model In Fig. 3b, the resources predicate is further refined into two states (available and used) thus two predicates (avail_R and used_R) are used to represent the states, correspondingly. Similarly, the assign transition at level 0 is refined to assign_t and release_t to behave the functions of assign resource(s) and release resource(s). Continuously, Fig. 3c shows the further refinements on the tasks predicate; three predicates (the open_Task, ready_to_assign and closed_Task) are used to represent available states of a task. Following this top-down analysis, the lowest-level net can be reached, in which components are represented by solid lines. The last modeling step is to labeling arcs with formal sum by tokens variables. Thus, a label hO, A, R, Ti constituted by token variables O, A, R and T is formed and attached to arcs in Fig. 3d. The token variable O indicates an order id; A indicates an activity (or operation)

Fig. 3b. Pr/Tr net model of resource planning (Level 1).

Fig. 3d. Pr/Tr net model of resource planning (Level 1 final).

number; R indicates a dispatching rule (including the rules used to select an order and resource(s)); and T indicates an available time information of a token. To run the Pr/Tr net model in Fig. 3d, initially, the order tokens are placed at the open_Task predicate and the resource tokens are placed at the avail_R predicate, respectively. Then, the setup_t transition will become enabled. After the triggers of the setup_t transition, order the tokens will be transited to the ready_to_assign predicate, waiting for resource planning. This time, if the resource(s) of activity A (expressed as R(A)) for an order is(are) available then the assign_t transition is friable. The selections of the order and resource tokens to fire depend on variables A and R. Whenever the assign_t is triggered, the selected order and resource tokens will be transited to the used_R predicate together, meanwhile, the time of the begin-use event will be arranged. Followed by this, transition release_t will be triggered and then the order token will be recycled to the open_Task predicate for next activity; meanwhile, the resource token will be returned to the avail_R predicate and the time of the end-use event will be recorded. The times of the events (begin-use and end-use) construct a duration (schedule) of resource usage. A terminal logical formula A = LA, inscribed in the complete_t transition, is used to check whether an order token has reached its last activity; the variable LA stores the last activity code while A stores the current activity code. Under this condition, the order token will be transited to the closed_Task predicate by the complete_t transition. Finally, when all the order tokens reside at the closed_Task predicate, it implies that the planning is down then the model may stop running. 4. Implementation 4.1. Approach for the development of the RPS A two-stage approach is used to implement the RPS: stage (1) design the data structure, and stage (2) develop the knowledge-based planning engine.

Fig. 3c. Pr/Tr net model of resource planning (Level 1 continued).

4.1.1. Design the data structure Four data structures are required for the RPS, including the resource, order, dispatching rule and schedule.

1846

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

• Resource: Fig. 4a shows the data items used for a resource token, including activity_code, company_ name, plant_name, resource_type, resource_id, time_ available_from, time_available_to and cost. The resource token is represented as a fact by Horn clause resource(activity_code,company_name,plant_name,resource_ type, resource_ id, time_avail_from, time_avail_to). • Order: Fig. 4b shows the data structure of an order token, which is represented as a fact by Horn clause order(customer, order_no, sublot_no, product_type, sale_ price, quantity, due_date, assign_company, assign_plant). The customer item indicates a customer name, the order_no indicates an order number, sublot_no indicates a sublot number. In addition, the assign_company and assign_plant are used to keep the names of assigned company and plant, respectively. • Dispatching rule: Fig. 4c shows the data structure of the dispatching rule, which is represented as a fact by Horn clause ruleset(select_order_rule,select_resource_ rule), the select_order_rule indicates the rule used to select an order and the select_resource_rule indicates the rule used to select resource(s). • Schedule: Fig. 4d shows the data structure of the schedule which is used to keep the planning results. The schedule is represented as a fact by Horn clause schedule(resource(company_name,plant_name,resource_ id),order(customer, order_no),operation,schedule_from, schedule_to). The schedule_from item is used to keep the time of begin-use event while the schedule_to item is used to keep the time of the end-use event.

4.1.2. Develop the knowledge-based planning engine The second stage to develop the RPS is to extract the rules from the Pr/Tr net and form a (knowledge) rule-based planning engine. A six-step procedure for establishing a RPS from a bottom-up view is proposed: (1) extract rules from predicates, (2) extract static transition logic rules from transitions, (3) transform the static transition logic rules into dynamic transition logic rules, (4) enable the iterative firings of the dynamic transition logic rules, (5) include (expert) knowledge to enhance system capability and (6) design goals for this RPS to reason. 1. Extract rules from predicates: according to the Fig. 3d, there are five predicates (open_Task, closed_task, ready_to_assign, avail_R, used_R) in the Pr/Tr net. Conceptually, tokens appear at predicates not only mark a specific state but also make these predicates true. This

Fig. 4b. Data structure for order token.

Fig. 4c. Data structure for dispatching rule.

Fig. 4d. Data structure for schedule.

concept can be transformed into logic rules. Take the statement ‘‘open_Task predicate is true if it appears a token’’ as an example, if the token appears as a fact in the form of open_Task_token(O, A, R, T) then the rule can be represented as open TaskðO; A; R; TÞ:- open Task tokenðO; A; R; TÞ: Similarly, the rules of the remaining predicates can be derived as follows: used RðO; A; R; TÞ:- used R tokenðO;A;R;TÞ; avail RðAÞ:- avail R tokenðO; A; R; TÞ; open TaskðO; A; R; TÞ:- open Task tokenðO;A;R;TÞ; closed TaskðO;A;R;TÞ:- closed Task tokenðO;A;R;TÞ: 2. Extract static transition logic rules from transitions: static transition rules are derived from transitions. Each transition corresponds to a ‘‘:-’’ symbol. According to the Pr/Tr net, there are four transitions (setup_t, assign_t, release_t and complete_t). Looking into the setup_t transition, it implies a rule of ‘‘ready_to_assign (O, A, R, T) is true if open_Task(O, A, R, T) is true’’. The rule is represented as ready to assignðO; A; R; TÞ:- open TaskðO; A; R; TÞ by Horn clause. Similarly, the other static transition logic rules can be derived and listed in Table 1.

Fig. 4a. Data structure for resource token.

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857 Table 1 Static transition logic rules for the Pr/Tr net model Transitions Rule no.

Rule contents

setup_t assign_t

ready_to_assign(O, A, R, T):- open_Task(O, A, R, T) used_R(O, A, R, T):- ready_to_assign(O, A, R, T), avail_R(A). open_Task(O, A, R, T):- used_R(O, A, R, T). closed_Task(O, A, R, T):- open_Task(O, A, R, T).

Rule 1 Rule 2

release_t Rule 3 complete_t Rule 4

3. Transform the static transition logic rules into dynamic transition logic rules: a dynamic transition logic rule is defined as a rule that can operate (transit) tokens. Thus, the static transition rules in Table 1 are modified by appending two functions (performed by retract and asserta predicates) to transform into dynamic transition rules (listed in Table 2). The retract predicate is used to remove a fact (corresponding to a token in the net) while the asserta predicate is used to insert a fact into the Prolog program; this simulates the ‘‘transition’’ of a token from one predicate to another after the firing of a transition in a Pr/Tr net. Additionally, note that in rule 1 a predicate get_next_activity(A, Next_A) is used to acquire the next activity, the variable A indicates a current activity while the Next_A responds the next activity. In rule 2, to fire the assign_t transition, the avail_R(A) (used to retrieve the available resource(s) for activity A) must be first satisfied. And, when the assign_t is fried, the selected order token will then be transited to used_R predicate. Rule 4 defines that if an order has completed its last activity (when A = LA), then the complete_t transition will be triggered and the order token will be transited to the closed_Task predicate. 4. Enable the iterative firings of dynamic transition logic rules: this step aims to invoke iterative firings of the four dynamic transition logic rules to simulate the running of the Pr/Tr net. To achieve this aim, a rule transitionðR; PÞ:- transitionðR; PÞ is appended to incur the recursive executions of the transition(R, P) predicate. In addition, the heads of the four dynamic transition logic rules are replaced by the transition(R, P) predicate so that the dynamic transition logic rules can be triggered subsequently. However, to

1847

stop the endless firings, the rule transition(R, P):- not(open_Task(_)), not(ready_to_assign(_)), not(used_R(_)),!. is placed at the top of the program as an ending condition; the ‘‘true’’ of the clause implies all order tokens reside at closed_Task predicate. Note that the variable P is used to keep the total value of profit resulted from applying the dispatching rule R transition(R, P):- not(open_Task(_)),not(ready_to_ assign(_)),not (used_R(_)),! transition(R, P):- open_Task(O, A, R, T), get_next_activity(A, Next_A), retract(open_Task_token (O,A·, R, T)), asserta (ready_to_assign_token (L, Next_A, R, T)). transition(R,P):- ready_to_assign(O, A, R, T), avail_R(A), retract(ready_to_assign_token (O, A, R, T)), asserta(used_R_token(O, A, R, T)). transition(R,P):- used_R(O, A, R, T), retract(used_R_token(O, A, R, T)), asserta(open_Task_token (O, A, R, T)), asserta(avail_R_token(A)). transition(R,P):- open_Task(O, A, R, T), A = LastActivity, retract(open_Task_token (O, A, R, T)),asserta (closed_Task_ token(O, A, R, T)), transition(R, P):- transition(R, P). 5. Include (expert) knowledge to enhance system capability: (expert) knowledge that are required (or can improve system performance) can be included in this step. Such as the knowledge of activity transition is expressed as get next activityðActivity; Next activityÞ:- Next activity ¼ Activity þ 1; where next activity (stored in Next_activity variable) is derived by increasing 1 to the current activity number (indicated by the variable Activity). 6. Design goals for this RPS to reason: the last step is to design and include the goals into the Prolog program so that it can start reasoning. One key point is to include

Table 2 Dynamic transition logic rules for the Pr/Tr net model Transitions

Rule no.

Rule contents

setup_t

Rule 1

assign_t

Rule 2

release_t

Rule 3

complete_t

Rule 4

ready_to_assign(O, A, R, T):- open_Task(O, A, R, T), get_next_activity(A,Next_A), retract(open_Task_token(O, A, R, T)), asserta(ready_to_assign_token(O,Next_A,R,T)). used_R(O, A, R, T):- ready_to_assign(O, A, R, T), avail_R(A), retract(ready_to_assign_token(O, A, R, T)), asserta(used_R_token(O, A, R, T)). open_Task(O, A, R, T):- used_R(O, A, R, T), retract(used_R_token(O, A, R, T)), asserta(open_Task_token(O, A, R, T)), asserta(avail_R_token(A)). closed_Task(O, A, R, T):- open_Task(O, A, R, T), A = LA, retract(open_Task_token(O, A, R, T)), asserta(closed_Task_token(O, A, R, T)).

1848

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

the ruleset(Rule) and simulate(Rule,Profit) predicates into the goal clause, thus both the two predicates can be further called. Below, two goal clauses are given to give more details. Goal 1: simulate_one(Rule, Profit):- ruleset(Rule), simulate (Rule, Profit). Goal 2: simulate_all(Rule, Profit):- ruleset(Rule), simulate (Rule, Profit), maxprofit(Max_Rule, Max_Profit). simulate(Rule, Profit):- transition(Rule, Profit), fail. simulate(Rule, Profit). Goal 1 is mainly aimed to illustrate a process of resource planning done by using a single dispatching rule. A reasoning tree which includes a DFS algorithm to explain the reasoning process is shown in Fig. 5a. To solve the goal clause simulate_one(Rule,Profit), ruleset(Rule) and simulate(Rule,Profit) predicates must be first solved in sequence.

The detailed reasoning steps are:(1) the Prolog program goes to solve the first predicate ruleset(Rule), (2) ruleset(Rule) unifies into database (3) the variable Rule is bound with the value ‘‘rule 1’’ and then ruleset(‘‘rule 1’’) indicates a ‘‘true’’ result (4) the Prolog program backs to predicate simulate_one(‘‘rule 1’’, Profit) (5) the Prolog program continues to solve the second predicate simulate(‘‘rule 1’’, Profit) (6) simulate(‘‘rule 1’’, Profit) solves (triggers) the transition(‘‘rule 1’’, Profit) predicate of the setup_t transition (7) backtracking occurs in predicate simulate(‘‘rule 1’’, Profit) (8) simulate(‘‘rule 1’’, Profit) triggers the transition(‘‘rule 1’’, Profit) predicate of the assign_t transition (9) backtracking occurs in predicate simulate(‘‘rule 1’’, Profit) (10) simulate(‘‘rule 1’’, Profit) triggers the transition(‘‘rule 1’’,Profit) predicate of the release_t transition (11) backtracking occurs in predicate simulate(‘‘rule 1’’, Profit) (12) if an order token completes all its activities then simulate(‘‘rule 1’’, Profit) triggers the complete_t transition (13) when all order tokens complete all their activities then the variable Profit will be bound with a value of ‘‘profit

Fig. 5a. The reasoning tree for goal 1.

Fig. 5b. The reasoning tree for goal 2.

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

1’’, meanwhile, the simulate(‘‘rule 1’’, ‘‘profit 1’’) will indicate a ‘‘true’’ result and the reasoning process goes to step 14, otherwise the reasoning process will be directed to step 6 (14) the reasoning process backs to simulate_one(‘‘rule 1’’, ‘‘profit 1’’) and concludes a ‘‘true’’ result. Step 1 to step 14 constructs a whole reasoning cycle which clearly shows the reasoning process of goal 1. Goal 2 is designed and used to illustrate the inclusion of ‘‘rule 2’’, in addition to ‘‘rule 1’’. In Fig. 5b, after two reasoning cycles are performed, ‘‘profit 1’’ and ‘‘profit 2’’

1849

which, respectively, resulted from ‘‘rule 1’’ and ‘‘rule 2’’ are derived. In goal 2, a predicate maxprofit(Max_Rule, Max_Profit) is additionally used to compare ‘‘profit 1’’ and ‘‘profit 2’’. Thus, the outperformed rule can be identified and the schedules based on this rule can be generated. Goal 2 also demonstrates the possibility and flexibility of including more than two rules into the RPS for evaluations. 4.2. System structure A RPS following the approach proposed in previous section is developed by using a logical programming language, Visual Prolog. Fig. 6 depicts the three main components, Graphic User Interface (GUI), Model and Knowledge Database (KB), of the RPS. The Model is the planning engine. The GUI provides a window environment for users to operate the RPS. The KB includes the related knowledge (facts or rules). Fig. 7 shows the GUI of the RPS. 5. An example case

Fig. 6. The system structure of the RPS.

To apply collaborative manufacturing, the manufacturing activities must be identified firstly. An Integrated Circuit (IC) assembly process is used in this example. The entire process of IC assembly includes wafer saw (W/S), die bond (D/B), wire bond (W/B), molding (M/D), laser mark (L/M), damber cut (D/C), solder plate (S/P), and trim and form (T/F) activities. Finally, a visual inspect

Fig. 7. The GUI of the RPS.

1850

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

(V/I) activity is performed to ensure the quality and then the assembled ICs are packed (P/K) and moved to a testing firm. Besides, a lot is assumed to split into sublots (1000 units) at the D/B activity. The costs of the activities are supposed available according to the ABC theory. In this example, goal 2 is used to compare two dispatching rules and generate the schedules. Meanwhile, participants A and B are assumed to conduct collaborative manufacturing by applying horizontal collaboration. 5.1. The input data The input data (including resource, dispatching rule, order, transportation time and transportation cost) are listed below. • Resource: Table 3 shows the activities, required resource(s), operation time and the cost of each activity on a specific resource of the two participants. The data shown in Table 3 are further transformed into facts listed in Appendix A.

• Dispatching rule: a dispatching rule consists of two rules; the order selection rule and the resource selection rule. Two dispatching rules are used in this example for evaluations. According to the data structure, ruleset(select_ order_rule, select_resource_rule), the two dispatching rules are represented as facts ruleset(‘‘EDD’’, ‘‘lwl’’), ruleset(‘‘EDD’’, ‘‘lct’’), where EDD: Earliest Due Date; Select the order with an earliest due date. lct: Least cost; Select the resource with least cost. lwl: Least work load; select the resource with least workload. • Order: ten orders are used in this example. According to the data structure, order(customer,order_no,sublot_ no,product_type,sale_price,quantity, due_date, assign_ company,assign_plant), the ten orders are represented as facts order(‘‘Customer1’’,00ao0100, 0, 00PDIP00, 350, 2000, 60, 0000, 0000).

Table 3 Resource data of the participants A and B Activity code (A)

Activity name

Resource required R(A)

Operation time

Participant A Machine No.

Cost

Machine No.

Participant B Cost

1

W/G

wafer grinder

2

No. 1 No. 2 No. 3

0.15 0.11 0.15

Nil

Nil

2

W/S

wafer saw

3

No. 1 No. 2 No. 3

0.20 0.18 0.20

Nil

Nil

3

D/B

die bonder

4

No. No. No. No. No.

1 2 3 4 5

0.32 0.28 0.32 0.29 0.32

Nil

Nil

4

W/B

wire bonder

2

No. No. No. No. No.

1 2 3 4 5

0.47 0.40 0.47 0.47 0.44

Nil

Nil

5

M/D

molder

3

No. 1 No. 2 No. 3

0.23 0.25 0.25

Nil

Nil

6

M/K

marker

4

No. 1 No. 2

0.24 0.21

No. 1 No. 2

0.20 0.18

7

D/C

dambar cutter

2

No. 1

0.15

No. 1

0.10

8

S/P

solder plating

3

No. 1 No. 2

0.27 0.23

No. 1 No. 2

0.21 0.19

9

T/F

trim/form

4

No. 1

0.19

No. 1

0.14

10

P/K

packing operator

2

No. 1

0.15

No. 1

0.16

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

order(‘‘Customer1’’, 00 ao0200, 0, 00PDIP00, 350, 2000, 61, 0000, 0000). order(‘‘Customer1’’, 00ao0300, 0, 00PDIP00, 350, 2000, 62, 0000, 0000). order(‘‘Customer1’’, 00ao0400, 0, 00PDIP00, 350, 2000, 63, 0000, 0000). order(‘‘Customer1’’, 00ao0500, 0, 00PDIP00, 350, 2000, 64, 0000, 0000). order(‘‘Customer1’’, 00ao0600, 0, 00PDIP00, 350, 2000, 65, 0000, 0000). order(‘‘Customer1’’, 00ao0700, 0, 00PDIP00, 350, 2000, 66, 0000, 0000). order(‘‘Customer1’’, 00ao0800, 0, 00PLCC00, 400, 2000, 67, 0000, 0000). order(‘‘Customer1’’, 00ao0900, 0, 00PLCC00, 400, 2000, 68, 0000, 0000). order(‘‘Customer1’’, 00ao1000, 0, 00PLCC00, 400, 2000, 69, 0000, 0000). • Transportation cost: the transportation cost is considered in the RPS, the cost required for each transfer between participants A and B is set to 50. • Transportation time: the transportation time is considered in the RPS, the time required for each transfer between participants A and B is set to 2 units. 5.2. The results After the resource planning done by the RPS with goal 2, the profit resulted from ruleset(00EDD00, 00lwl00) is 1,245,760 while the profit resulted from ruleset(00EDD00, 00lct00) is 1,246,080. Thus, the rule ruleset(00EDD00, 00lct00) is suggested. The schedules generated by ruleset(00EDD00, 00lct00) for participants are shown in Appendixes B and C.

1851

devoted to propose a systematic approach for developing a RPS in supporting the operations of a VE. Thus, a systematic approach which includes steps of top-down analysis and bottom-up implementation is proposed in this study. Following the approach, a Pr/Tr net model for resource planning is derived and it can be easily and directly transformed into Horn clauses and implemented by Visual Prolog, and a RPS is finally developed. The RPS has the following advantages: (1) It is a rule-based system thus goals, dispatching rules and expert knowledge are easily to be included, (2) The system can automatically evaluate alternative dispatching rules and suggest the best one, meanwhile, create the schedules. Thus, it seems that less human intervention is required. (3) ABC concept is included so that cost/profit information, a financial measure, can be provided. A financial measure is thought to be more meaningful in a collaborative environment and useful for supply chain management (SCM). This study puts much effort on the implementation phase, because it is believed to be important in practical application but was seldom elaborated in past studies. In addition, the development of the Pr/Tr net model and the transformation of it into Horn clause are detailed in a systematic approach. The can shorten the gap between the modeling and implementation phases. Moreover, the Pr/ Tr net model derived in this study is quite general thus it can be quickly applied to other similar application areas, if the activities of the application areas can be defined and the resource(s) of activities can be analyzed within a short time. An example in this study has demonstrated the application capability of the RPS. Although the example is focused on horizontal collaboration, the vertical and lateral collaborations seemed are applicable. Thus, future research direction is implied.

6. Conclusion VE has been regarded as a strategy enabling SMEs to alley and survive in a competitive environment and some of the past research had paid attention to this. However, relatively little research attention so far seems to have been

Acknowledgements This work is supported by the National Science Council of Taiwan, R.O.C., project no. NSC94-2213-E-159-010.

Appendix A. The resources • Resources released from participant A resource(1, 00A00, 00Plant 100, 00 wafer grinder00, 00No. 100, 0, 9999999, 0.15). resource(1, 00A00, 00Plant 100, 00 wafer grinder00, 00No. 200, 0, 9999999, 0.11). resource(1, 00A00, 00Plant 100, 00 wafer grinder00, 00No. 300, 0, 9999999, 0.15). resource(2, 00A00, 00Plant 100, 00 wafer saw00, 00No. 100, 0, 9999999, 0.20). resource(2, 00A00, 00Plant 100, 00 wafer saw00, 00No. 200, 0, 9999999, 0.18). resource(2, 00A00, 00Plant 100, 00 wafer saw00, 00No. 300, 0, 9999999, 0.20). resource(3, 00A00, 00Plant 100, 00 die bonder00, 00No. 100, 0, 9999999, 0.32). resource(3, 00A00, 00Plant 100, 00 die bonder00, 00No. 200, 0, 9999999, 0.28). resource(3, 00A00, 00Plant 100, 00 die bonder00, 00No. 300, 0, 9999999, 0.32). resource(3, 00A00, 00Plant 100, 00 die bonder00, 00No. 400, 0, 9999999, 0.29). resource(3, 00A00, 00Plant 100, 00 die bonder00, 00No. 500, 0, 9999999, 0.32). resource(4, 00A00, 00Plant 100, 00 wire bonder00, 00No. 100, 0, 9999999, 0.47).

1852

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

resource(4, 00A00, 00Plant 100, 00 wire bonder00, 00No. 200, 0, 9999999, 0.40). resource(4, 00A00, 00Plant 100, 00 wire bonder00, 00No. 300, 0, 9999999, 0.47). resource(4, 00A00, 00Plant 100, 00 wire bonder00, 00No. 400, 0, 9999999, 0.47). resource(4, 00A00, 00Plant 100, 00 wire bonder00, 00No. 500, 0, 9999999, 0.44). resource(5, 00A00, 00Plant 100, 00 molder00, 00No. 100, 0, 9999999, 0.23). resource(5, 00A00, 00Plant 100, 00 molder00, 00No. 200, 0, 9999999, 0.25). resource(5, 00A00, 00Plant 100, 00 molder00, 00No. 300, 0, 9999999, 0.25). resource(6, 00A00, 00Plant 200, 00marker00, 00No. 100, 0, 9999999, 0.24). resource(6, 00A00, 00Plant 200, 00marker00, 00No. 200, 0, 9999999, 0.21). resource(7, 00A00, 00Plant 200, 00 damber cutter00, 00No. 100, 0, 9999999, 0.15). resource(8, 00A00, 00Plant 200, 00solder plating00, 00No. 100, 0, 9999999, 0.27). resource(8, 00A00, 00Plant 200, 00solder plating00, 00No. 200, 0, 9999999, 0.23). resource(9, 00A00, 00Plant 200, 00trim/form00, 00No. 100, 0, 9999999, 0.19). resource(10, 00A00, 00Plant 200, 00packing operator00, 00No. 100, 0, 9999999, 0.15). • Resources released from participant B resource(6, 00B00, 00plant 100, 00marker00, 00No. 100, 0, 9999999, 0.18). resource(6, 00B00, 00plant 100, 00marker00, 00No. 200, 0, 9999999, 0.16). resource(7, 00B00, 00plant 100, 00 damber cutter00, 00No. 100, 0, 9999999, 0.10). resource(8, 00B00, 00plant 100, 00solder plating00, 00No. 100, 0, 9999999, 0.20). resource(8, 00B00, 00plant 100, 00solder plating00, 00No. 200, 0, 9999999, 0.17). resource(9, 00B00, 00plant 100, 00trim/form00, 00No. 100, 0, 9999999, 0.14). resource(10, 00B00, 00plant 100, 00packing operator00, 00No. 100, 0, 9999999, 0.16).

Appendix B. The schedule for participant A By ruleset(00EDD00, 00lct00) Total Revenue = 1,290,000 Profit = 1,246,130 Transportation cost = 50 Net profit: 1,246,080 Activity Ord No.

Sub No.

Company Plant

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

A A A A A A A A A A A A A A A A A A A A A A A A

ao01 ao02 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao02 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao02 ao03 ao04

Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Qty

Resource type

Resource id Schedule From

Schedule To

2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000 2000

wafer grinder wafer grinder wafer grinder wafer grinder wafer grinder wafer grinder wafer grinder wafer grinder wafer grinder wafer grinder wafer saw wafer saw wafer saw wafer saw wafer saw wafer saw wafer saw wafer saw wafer saw wafer saw die bonder die bonder die bonder die bonder

No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No.

2 2 2 4 4 4 6 6 6 8 5 5 5 8 8 8 11 11 11 14 9 9 9 12

2 3 1 2 3 1 2 3 1 2 2 3 1 2 3 1 2 3 1 2 2 4 5 3

0 0 0 2 2 2 4 4 4 6 2 2 2 5 5 5 8 8 8 11 5 5 5 8

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

1853

Appendix B (continued) Activity Ord No.

Sub No.

Company Plant

3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6

0 0 0 0 0 0 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 2 1 2 1 2 2 2

A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A

ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao02 ao02 ao03 ao03 ao04 ao04 ao05 ao05 ao06 ao06 ao07 ao07 ao08 ao08 ao09 ao09 ao10 ao10 ao01 ao01 ao02 ao02 ao03 ao03 ao04 ao04 ao05 ao05 ao06 ao06 ao07 ao07 ao08 ao08 ao09 ao09 ao10 ao10 ao02 ao02 ao03 ao04 ao05 ao06 ao07

Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2

Qty

Resource type

Resource id Schedule From

2000 2000 2000 2000 2000 2000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000

die bonder die bonder die bonder die bonder die bonder die bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder wire bonder molder molder molder molder molder molder molder molder molder molder molder molder molder molder molder molder molder molder molder molder marker marker marker marker marker marker marker

No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No.

1 2 4 5 3 2 2 5 4 3 1 2 5 4 3 1 2 5 2 4 3 1 5 2 5 4 1 3 2 1 3 2 1 3 2 1 3 2 1 3 2 1 3 2 1 3 2 1 1 2 1 2 1

8 9 11 11 12 14 9 9 9 9 9 11 12 12 12 12 13 14 15 15 15 15 16 17 18 18 11 11 11 14 14 14 17 17 17 20 20 20 23 23 23 26 26 26 29 29 17 14 18 21 23 25 27

Schedule To

12 13 15 15 16 18 11 11 11 11 11 13 14 14 14 14 15 16 17 17 17 17 18 19 20 20 14 14 14 17 17 17 20 20 20 23 23 23 26 26 26 29 29 29 32 32 21 18 22 25 27 29 31 (continued on next page)

1854

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

Appendix B (continued) Activity Ord No. Sub No. Company Plant 6 6 6 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 10 10

ao08 ao09 ao10 ao02 ao02 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao02 ao02 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao02 ao02 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao02 ao02 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10

2 2 2 1 2 2 1 2 2 2 2 2 2 2 1 2 1 2 2 2 2 2 2 1 2 2 1 2 2 2 2 2 2 2 1 2 1 2 2 2 2 2 2

A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A

Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant

2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

Qty

Resource type

Resource id Schedule From Schedule To

1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000

marker marker marker damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator

No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No.

2 1 2 1 1 1 1 1 1 1 1 1 1 2 1 1 2 1 2 1 2 1 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

29 31 33 18 21 23 25 27 29 31 33 35 37 23 20 25 27 29 31 33 35 37 39 23 27 31 35 39 43 47 51 55 59 31 33 35 39 43 47 51 55 59 63

33 35 37 20 23 25 27 29 31 33 35 37 39 26 23 28 30 32 34 36 38 40 42 27 31 35 39 43 47 51 55 59 63 33 35 37 41 45 49 53 57 61 65

Appendix C. The schedule for participant B By ruleset(00EDD00, 00lct00) Total Revenue = 1,290,000 Profit = 1,246,130 Transportation cost = 50 Net profit: 1,246,080 Activity Ord No.

Sub No.

Company Plant

Qty

6 6

2 1

B B

1000 marker 1000 marker

ao01 ao01

Plant 1 Plant 1

Resource type

Resource id Schedule From

Schedule To

No. 2 No. 1

20 20

16 16

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

1855

Appendix C (continued) Activity Ord No. Sub No. Company Plant 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 10 10 6 6 6 6 6

ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05

1 2 1 1 1 1 1 1 1 2 1 2 1 1 1 1 1 1 2 1 1 2 1 1 1 1 1 1 1 2 1 2 1 1 1 1 1 1 2 1 1 2 1 1 1 1 1 1 2 1 1 2 1

B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B

Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Qty

Resource type

Resource id Schedule From Schedule To

1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000

marker marker marker marker marker marker marker marker damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator marker marker marker marker marker

No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No.

2 1 2 1 2 1 2 1 1 1 1 1 1 1 1 1 1 1 2 1 1 2 1 2 1 2 1 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 2 1 2

20 22 24 26 28 30 32 34 20 22 24 26 28 30 32 34 36 38 24 22 26 28 30 32 34 36 38 40 25 29 33 37 41 45 49 53 57 61 33 35 37 41 45 49 53 57 61 65 16 16 20 22 24

24 26 28 30 32 34 36 38 22 24 26 28 30 32 34 36 38 40 27 25 29 31 33 35 37 39 41 43 29 33 37 41 45 49 53 57 61 65 35 37 39 43 47 51 55 59 63 67 20 20 24 26 28 (continued on next page)

1856

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857

Appendix C (continued) Activity Ord No. Sub No. Company Plant 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 10 10 10 10 10 10 10 10 10 10

ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10 ao01 ao01 ao03 ao04 ao05 ao06 ao07 ao08 ao09 ao10

1 1 1 1 1 1 2 1 2 1 1 1 1 1 1 2 1 1 2 1 1 1 1 1 1 1 2 1 2 1 1 1 1 1 1 2 1 1 2 1 1 1 1 1 1

B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B

Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant Plant

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Qty

Resource type

Resource id Schedule From Schedule To

1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000

marker marker marker marker marker damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter damber cutter solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating solder plating trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form trim/form packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator packing operator

No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No. No.

References Chow, W. S., & Li, J. Y. (1997). Higher-order Petri net models based on artificial neural networks. Artificial Intelligence, 92, 289– 300. Cooper, R., & Kaplan, R. S. (1988). How cost accounting distorts product costs. Management Accounting, 69(10), 20–27. Fisher, J. (1992). Use of non-financial performance measures. Journal of Cost Management, 6(1), 31–38.

1 2 1 2 1 1 1 1 1 1 1 1 1 1 1 2 1 1 2 1 2 1 2 1 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

26 28 30 32 34 20 22 24 26 28 30 32 34 36 38 24 22 26 28 30 32 34 36 38 40 25 29 33 37 41 45 49 53 57 61 33 35 37 41 45 49 53 57 61 65

30 32 34 36 38 22 24 26 28 30 32 34 36 38 40 27 25 29 31 33 35 37 39 41 43 29 33 37 41 45 49 53 57 61 65 35 37 39 43 47 51 55 59 63 67

Genrich, J. J. (1987). Predicate/Transition Nets. Lecture notes in computer science, 205, 207–247. Genrich, H. L., & Lautenbach, K. (1986). System modelling with highlevel Petri net. Theoretical Computer Science, 13, 109–136. Giordana, A., & Saitta, L. (1985). Modeling production rules by means of predicate/transition networks. Information Science, 35, 1–41. Glassey, C. R., & Resende, M. C. G. (1988). Closed-loop job release control for VLSI circuit manufacturing. IEEE Transactions on Semiconductor Manufacturing, 1, 36–46.

H.-P. Hsu, H.-M. Hsu / Expert Systems with Applications 35 (2008) 1841–1857 Hsu, H. P., Chen, J. Y., & Su, C. T. (2004). An activity-based predicate/ transition net model of operational control planning for a flexible manufacturing system. International Journal of Advanced Manufacturing Technology, 23, 594–605. Hsu, H. P., & Su, C. T. (2005). The implementation of an Activity-Based Costing collaborative production planning system for semiconductor backend production. International Journal of Production Research, 43(12), 2473–2492. Huang, S., Hu, Y., & Li, C. (2004). A TCPN based approach to model the coordination in virtual manufacturing organization. Computers and Industrial Engineering, 47, 61–76. Huang, Y. H., & Leachman, R. C. (1996). A production planning methodology for semiconductor manufacturing based on iterative simulation and linear programming calculations. IEEE Transactions on Semiconductor Manufacturing, 9(2), 257–269. Janneck, J. W., & Naedele, M. (1998). Modeling a Die Bonder with Petri Nets: A case study. IEEE Transactions on semiconductor manufacturing., 11(3), 405–409. Johri, P. K. (1993). Practical issues in scheduling and dispatching in semiconductor wafer fabrication. Journal of Manufacturing system, 1(12), 474–485. Koestler, A. (1989). The Ghost in the Machine. London: Arkana Books. Laitinen, E. K. (2002). A dynamic performance measurement system: evidence from small Finnish technology companies. Scandinavian Journal of Management, 18, 65–99. Mezgar, I., Kovacs, G. L., & Paganelli, P. (2000). Co-operative production planning for small- and medium-sized enterprises. International Journal of Production Economics, 64, 37–48. Murata, T. (1989). Petri nets: properties, analysis and application. Proceedings of the IEEE, 77(4), 541–580. Murata, T., & Zhang, D. (1988). A predicate/transition net model for parallel interpretation of logic programming. IEEE Transactions on Software Engineering, 14(4), 481–497.

1857

Ong, N. S. (1995). Manufacturing cost estimation for PCB assembly: An activity-based approach. International Journal of Production Economics, 38, 159–172. Peterka, G., & Murata, T. (1989). Proof procedure and answer extraction in Petri net model of logic programs. IEEE Transactions on Software Engineering, 15, 209–217. Pirttila, T., & Hautaniemi, P. (1995). Activity-based costing and distribution logistics management. International Journal of Production Economics, 41, 327–333. Salafatinos, C. (1996). Modeling resource supply and demand: Expanding the utility of ABC. International Journal of Production Economics, 43, 47–57. Schmidt, B. G. (1996). Modeling production scheduling system. International Journal of Production Economics, 46–47, 109–118. Spearman, M. L., Woodruff, D. L., & Hopp, W. J. (1990). CONWIP: A pull alternative to kanban. International Journal of Production Research, 28, 879–894. Togar, M. S., & Sridharan, R. (2002). The collaborative supply chain. International Journal of Logistics Management, 13(1), 15–30. Uzsoy, R., & Lee, C. Y. (1992). A review of production planning and scheduling models in the semiconductor industry. Part I: System characteristics, performance evaluation and production planning. IIE Transaction, 24, 47–60. Wein, L. M. (1988). Scheduling semiconductor wafer fabrication. IEEE Transactions on Semiconductor Manufacturing, 1(3), 115–130. Xu, X., Ye, D., & Li, Q. (2005). Dynamic organization and methodology for agile virtual enterprises. Journal of Computer Science and Technology, 15(4), 368–375. Yan, H. S., Wang, N. S., Zhang, J. G., & Cui, X. Y. (1998). Modeling, scheduling and simulation of flexible manufacturing systems using extended stochastic high-level evaluation Petri nets. Robotics and Computer-Integrated Manufacturing, 14, 121–140.