Design the goals for this expert system to explore: The final step (highest level work) is to design the goals for this system to explore. During the

reasoning process of the goal, transition rules are invoked by simulate(Rule, Profit) in order to simulate the task assignment process. When a schedule is planned and the outcomes compliant to the goal, then schedule is feasible, otherwise suggestions may be provided by the knowledge base. Two goal examples are given below to give more detail explanation.

Goal 1: simulate_one(Rule,Profit):-ruleset(Rule), simulate(Rule,Profit).

Goal 2: simulate_all(Rule,Profit):-ruleset(Rule), simulate(Rule,Profit), max_ profit (Max_Rule,Max_Profit).

simulate(Rule,Profit):-transition(Rule,Profit), fail.

simulate(Rule,Profit).

A reasoning tree is depicted by Figure 5.2(a), which gives an example for the expert system to explore the goal 1. Goal 1 is simply designed to implement the single use of a dispatching rule. For the clause that refers to goal 1 to be true, the

condition, predicate ruleset(Rule) must be satisfied firstly, therefore ruleset(Rule) unifies into the database by the depth first search mechanism embedded in logic program, and then variable Rule binds to the value ”rule1”, after passing this value to the 2^nd predicate simulate(Rule, Profit) in the Hone clause, simulate(“rule1”, Profit) is then tried to be satisfied secondly, this incurs the iterative firings of the transitions in the ABC Pr/Tr Net until the boundary clause (condition) is satisfied. Then the output variable, Profit, indicates the profit information by using the dispatching rule, “rule1”. According to ABC theory, analyzing the cost drivers can derive the cost for each activity. Therefore, if the sales price for each order is known, then the profit can be calculated.

Goal 1:

simulate_one(Rule, Profit)

simulate("rule1",Profit)

O W U("rule1", Profit) F

transition( ) transition( ) transition("rule1", Profit) transition( ) ruleset(Rule)

rule1

facts (tokens) fact

<order>

(1) (4)

(14)

(7) (9) (10) (12)

(5)

(6) (8)

(11) (2) (3)

(13)

transition( )

(15) (16)

E

Figure 5.2(a) A reasoning tree for goal 1

transition( )

Figure 5.2(b) A reasoning tree for goal 2

To extend the exploration of alternative solutions, goal 2 is designed to illustrate the search of the solution space for finding another superior solution in the point view of maximum profit. Figure 5.2(b) shows the reasoning sequences in a tree for all the available dispatching rules. Firstly, “rule1” is unified by predicate ruleset(Rule) and bound to variable Rule, and then simulate(“rule1”, Profit1) is invoked and triggering the fires of transitions. A collaborative schedule will be created and profit information (Profit 1) will come out after a simulation run. In the next step, ruleset(Rule) unifies into database and binds the variable Rule with value “rule2”, simulate(“rule2”,Profit2) is invoked again, and profit information (Profit2) is got. Lastly, the final predicate maxprofit(Max_Rule, Max_Profit) is executed to suggest the superior solution from the alternatives and the collaborative schedule is suggested, too. Obviously, rules are appendable, and other goals can be easily set up to extend or empower the system capability.

5.3 System Structure of ABC/CPPS

As depicted in Figure 5.3, there are three main components in this expert scheduling system, the Graphic User Interface (GUI), the collaborative scheduling model (Model) and the knowledge database (KB) module. The collaborative scheduling module with simulation knowledge and expert knowledge incorporated is the kernel of this system. The GUI that is developed by Visual Prolog, providing a window environment to select a goal (or query) for reasoning, is shown in Figure 5.4. Collaborative schedule is created after the simulation run and passed to a web site for directly accessing from the Internet, or data in XML format could be created for data exchange among the collaborative members.

In practice, the expert scheduling system is useful both in internal and/or collaborative scheduling. For internal use, each collaborative member can run its own autonomous schedule first, and then release the free capacity (collaborative resources) to virtual enterprise for further creating the collaborative manufacturing schedule. The two-stage procedure keeps both the autonomous and collaborative planning feasible.

User interface

1. collaborative schduling model 2.expert knowledge

1. dispatching rules 2. orders 3. resources 4. process time 5. cost

goals query schedule

suggestions

GUI

Model KB

Figure 5.3 The system structure for ABC/CPPS

Figure 5.4 The GUI of the ABC/CPPS

5.4 Web Publish and Data Exchange

To facilitate the implementation of collaborative production, a collaborative production planning system (CPPS) is required. As shown by Figure 5.5, a collaborative planning model is built to serve as the planning engine based on available collaborative resources. After the collaborative manufacturing schedule is planned, the results may be either published to web server which is directly assessable by browser from the client, or transferred to each member by using XML-formatted file. Based on the web-server architecture and the Internet infrastructure, collaborative members can be networked through the Internet to provide a collaborative scheduling/manufacturing environment.

About the markup language, Standard Generalized Markup Language (SGML), HyperText Markup Language (HTML) and eXtensible Markup Language (XML) are the three most important ones. Each language has a unique purpose. SGML is a rich meta language that is useful for defining an almost endless supply of markup languages. HTML is useful for displaying Web pages.

XML, is the extensible markup language, and was developed from SGML. Now

XML is becoming a standard way for people to export and import data from different systems. Its simplicity makes it easy for different systems to exchange data. Details about the XML data transformation in ABC/CPPS are presented in next chapter.

The Internet Collaborative

Capacity

Plant 1

Plant 2

Plant 3

Collaborative Planning

model

Company A

Web Server

Plant 2

Company B collaborative

resource

collaborative resource

collaborative schedule

Plant 1 client

client collaborative VE

schedule

collaborative schedule

DB

DB client

XML/HTTP XML/HTTP

XML XML

Figure 5.5 Client/Server wet site structure

CHAPTER 6