A Semi-automatic Task Decomposing Way based on QoS in

A Semi-automatic Task Decomposing Way based on QoS in

Manufacturing Grid

1

Yuan He,

Fuyang Chen,

Qi Zhu,

Xinwang Song

School of Mechanical Engineering, Shanghai Institute of Technology, Shanghai, China,

[email protected], [email protected], [email protected], [email protected]

Abstract

A manufacturing task in manufacturing grid (MG) must be decomposed into many subtasks or activities, so that to match every subtask or activity with a manufacturing resource, and make the subtasks or activities working effectively using the geographically distributed, heterogeneous manufacturing resources in synchronization. Since the complexity of the manufacturing tasks and resources, it is impossible for us to decompose the manufacturing tasks with an automatic way completely. It is believed that the task decomposing is an application middleware in MG. We proposed a QoS-based task semi-automatic decomposing approach of combining automation with manpower, i.e. searching a task’s successful case database and decomposing the task with global process planning (GPP) analyzing automatically, then decomposing the task by a project manager or a specialist. Furthermore, an application example is proposed to illustrate the decomposing process.

Keywords

Manufacturing

1. Introduction

With the rapid development of the manufacturing grid (MG) technology, people have begun to pay attention to its applications. In order to reduce the manufacturing cost and raise using rate of manufacturing resources in manufacturing industry, the goal of MG is to share manufacturing resources across the geographical zones and enterprises, to realize collaborative design and manufacturing, to make up of dynamic alliance (DA) or virtual organization (VO) dynamically according to the market. MG emerging with the grid technology can overcome many disadvantages of networked manufacturing (NM): [1] NM hasn’t uniform criterion, it uses the different methods and technologies, limits to a certain industry or a product, and is difficult to spread and popularize [2].

Grids are classified into two major categories in grid applications: computing grids and accessing grids. As an accessing grid, MG provides a collaborative environment, resources and services. Customers can access the MG through a browser. In the MG platform, every task submitted by customers can not be accomplished by a resource but achieved by more resources cooperative working [3]. In order that every manufacturing task can make effectively use of the geographically distributed, heterogeneous manufacturing resources in synchronization, the whole task must be decomposed into subtasks or activities, the process is called task decomposing (TD). Only by TD, can subtasks or activities be matched with manufacturing resources belonging to different resource nodes, and change into actual grid resources. So, TD is the common service between grid platform (hardware and operation system) and application, a kind of middleware [4].

We proposed the basic principles of TD of MG, and a QoS (Quality of Service)-based TD method by searching successful case database, decomposing a task with global process planning (GPP) analyzing, and a task decomposed by a project manager and a specialist.

2. Related works

2.1. The concept and function of grid middleware

A traditional middleware is a sort of software between application software and system software, or a kind of software between customers and service providers, or a middle product needed to be developed twice. As a kind of service, grid middleware is distinguished from a traditional middleware, the grid middleware is a kind of software between grid platform and grid application. Aiken, R. and

Carey, M. gives the concept in the article of Network Policy and Services: A Report of a Workshop on Middleware, “the services needed to support a common set of applications in a distributed network environment”. [5]

Grid core middleware is the key layer in framework, it is a tie linking the upper application layer and the lower resource layer, and provides the function of management for grid. [6]

The grid middleware hides the complexity of the grid platform, makes the program designer facing a simple and uniform developing environment, decreasing the complicacy of program design, the technological difficulties, the program developing cycle, the workloads of maintenance, running, managing of the system and the whole expenditure of computers.[7]

2.2 MG system framework and task decomposing middleware

With the open grid service architecture (OGSA) as the system framework, globus toolkit 3 (GT3) as the developing middleware, [8] MG as “Standard and open protocol-based resource sharing and cooperative working in dynamic, distributed, decentralized control virtual manufacturing enterprises to deliver nontrivial qualities of service”. MG is made up of a number of components from enabling resources to end user applications. A layered system framework of MG is shown in Figure 1.

Figure 1. MG System Framework and Middleware

The key components of MG include: [9]

 MG Applications: MG applications face to all the field and industries of manufacturing, include aviation, automobile, shipping, electric, medicine, etc, are typically developed using Java language. MG Portal offers Web-enable application services, where customers can submit and collect results of their products through the Web.

 MG Application Middleware: This is expansion of MG core middleware, includes product

manufacturing environments (CSCW), Task Decomposing (TD), performance evaluating and monitoring tools, and Manufacturing Grid Resource Scheduling (MGRS) for scheduling manufacturing tasks on global resources.

 MG Core Middleware: This offers core services provided by GT3, such as security, resource

co-allocation, resource management, data management, etc.

 MG Fabric: This consists of all the globally distributed manufacturing resources that are accessible from anywhere on the Internet. Various kinds of manufacturing resources, design software or machine tools, can be encapsulated into grid services if only they measure up to the uniform MG interface.

Because the characteristics of manufacturing tasks differ in thousands ways, task decomposing middleware (TDM) is not a common middleware, but an application middleware. Thus, the TDM is the main composition of application middleware. As a MG middleware, TDM has the interface with workflow and MG-QoS, this is the main differences with other grid’s TDM.

3. The definitions and principles of task decomposing based on QoS

3.1 The definitions and functions of task decomposing in MG

The manufacturing of a product can’t accomplish by a single resource in manufacturing, but more resources sharing and cooperative working. In order that every manufacturing task can make effectively use of the geographically distributed, heterogeneous manufacturing resources in synchronization, the whole task must be decomposed into many subtasks or activities, so as to ensure the whole manufacturing process is parallel, with high quality control. Subsequently, the resources which will fulfill the subtasks will be confirmed through the resource discovery and resource scheduling, forming a task workflow by workflow module.

The function of TD is to describe the task with a standard language called eXtensible Markup Language (XML), the contents described is task name, task type and QoS constraints of the task. Then project manager decomposes the task according to the resources, and the subtasks are changed into actual grid resource. Another function of TD is to incorporate the subtasks which have been decomposed.

A QoS-based MG task decomposing is to decompose the task submitted by customers into a series subtasks and activities according to the task’s QoS constraints. The QoS constrains is about the customer’s requirements, which normally be called TQPS (Time, Quality, Price, and Service), that is, the requirements for a specified task are not only time or performance, but also other criteria, such as user satisfaction, product quality and service, time to market, and price, etc,

Before beginning the QoS-based TD research, we make two basic definitions at first.

Definition 1: Tasks submitted in MG are always products that a customer wants. A task is usually composed of several working procedures in a pre-defined sequence. We define task as follows:

{ , , , , }

TS  TN TL TI TO TQoS (1) Where:

TS--Manufacturing task. TL-- The quantity of the task. TN-- The name of the task.

TI-- The input format of the task, such as: 2D or 3D CAD model, photographs, etc. TO-- The outcome format of the task, such as: design model or products.

TQoS-- The task’s QoS Requirements, which define the constraint characteristics of the task: { _s, _e, , , }

TQoS TS TS TQ TP S (2) Where:

s

TS -- The start time of the task.

TQ-- The quality constraints of the task.

e

TS -- The end time of the task. TP-- The price constraints of the task. S-- The service requirements of the task.

Definition 2: Task can be decomposed into subtasks. Subtask is a subset of the task, which can be a component or a part.

{ _i} 1, 2, ,

TS TS i n.

TS

i

{ , , , }

i i i i i

TS  TN TL TO TQoS (3) The meanings of the variables are the same as Eq. (1).

3.2 Principles of task decomposing in MG

Task decomposing is a layered tree structure with the root node of a product. When a manufacturing task is decomposed, one must abide by the general principles, the principles are as follows:

 Independent principle. The subtasks should be independent in functions to each other, so as to decrease the mutual collaborating and communicating.

 The principle of combining tasks oriented and the resources oriented. In the early of MG

building, the MG platform is lack of registered resources, it’s better to follow the principle of resource oriented. When the resources of MG platform are sufficient, the better principle is to follow the principle of task oriented.

 Function principle. The decomposition of task can be in terms of functions, and the subtasks should be completed in different independent resources.

 Hierarchical principle. One complicated task can be divided into a few of subtasks, and the

subtasks can be decomposed into other simple, easy-handled, lower subtasks.

 Proportional principle. The subtasks should be in an average execution time to avoid the low efficiency of the entire system.

 The principle of granularity. The subtasks should not be decomposed if they can be accomplished by a single enterprise.

 The principle of composing the same kinds of subtasks. The subtasks can be composed to one if they are the same type.

 Structural principle. According to the structure of the product, the task should be decomposed into some parts or components.

To different products in manufacturing, these principles can be used alone or integrated depending on the specific case.

3.3 The process of task decomposing of MG

Figure 2.shows the process of task decomposing. The basic process is as follows: Firstly, searching the Successful Case Database (SCD) to look up successful cases. Secondly, if no successful case is found, the GPP（Global Process Planning）analyzing is used to decompose the task. Thirdly, a project manager decomposes the GPP results again with a software tool (Ex. Work Break Down chart pro). At last, a specialist verifies or modifies the results of task decomposing. Then the results of task decomposing will use to resources scheduling.

Figure 2. Basic Process of Task Decomposing

3.3.1 Searching successful cases

According to the types and characteristics of tasks, we adopt the matching method of characteristics and resembling through the searching engine, to look up the same and similar task decomposing cases in the SCD. If there is a successful case, then show the results in the JSP (Java Server Page) page, if there isn’t any, then GPP analyzing will be used to decompose the task.

3.3.2 GPP analyzing decomposing

Global process planning (GPP) analyzing is characterized by performing the following activities in virtual organization (VO) or virtual enterprise (VE):

 Submitted task’s analyzing, confirm the classification by its type and QoS requirements;  Task mapping based on characteristics and comparability;

 Task decomposing or composing based on decomposing rules;  Task decomposing based on QoS requirements.

Its framework is shown in Figure 3.

In this framework, GPP Analyzing Center will perform the functions depicted above with the help of Task Mapping Database and Task Decomposing Rule Base. The former, Task Mapping Database, contains products and their workflow solutions generated from expert knowledge or experiences and can be referenced for analyzing. And the latter, Task Decomposing Rule Base, contains the rules for subtasks’ composing or decomposing and offers sufficient principles one must abide by during analyzing.

In rapid manufacturing, the modes of the tasks submitted by customers mainly comprise of the four kinds of styles: (1) CAD models, including 2D and 3D models; (2) the entities of the product; (3) photographs or pictures; (4) STL files.

Corresponding to the modes of task submitting, the four kinds of task types are as follows:  Design tasks: including the processes of rapid design (CAD) or reverse engineering (RE)

and rapid simulation.

 Rapid prototype tasks: including the processes of rapid design, assembly, rapid simulation and rapid prototype.

 Rapid tooling tasks: including the processes of rapid design, rapid simulation, rapid

prototype and rapid tooling.

 Service tasks: including the processes of inquiry and consultation.

In the process of GPP decomposing, the system determines the task’s field firstly according the task modes and types, and chooses a same or similar GPP template if existed, and transfers it automatically. The GPP template is a XML document as a matter of fact. For example, if the mode of a task submitted is a photo and the task type is rapid prototype, then the GPP program for the task is shown in Table 1.

Table 1. XML document of GPP template <?xml version="1.0" encoding="gb2312"?>

<!DOCTYPE GPP>

<!-- this is a template file for some GPP--> <GPP>

<Process>

<process_id>1</process_id>

<process_name>rapid design</process_name> </Process>

<Process>

<process_id>2</process_id>

<process_name>rapid assembly</process_name> </Process>

<Process>

<process_id>3</process_id>

<process_name>rapid simulation</process_name> </Process>

<Process>

<process_id>4</process_id>

<process_name>rapid prototype</process_name> </Process>

</GPP>

A new GPP template can be created to enrich the Task Mapping Data Base of MG platform, and a GPP template can also be examined, modified and deleted.

The process of searching successful case database and GPP analyzing decomposing are accomplished automatically, and the process of the project manager and specialist decomposing are achieved manpower with the help of some software.

The project manager and specialist who are familiar with the specific manufacturing field will continue to decompose the results of GPP decomposing. For they have much experiences in the specific field, so they can give much more detailed workflow. Figure 4 is a sketch map of task decomposing and composing.

Decomposing Subtask_D Task_A Task_C B_3 and C_1 Composing B_1 B_2 B_3 Task_B C_1 C_2

Figure 4. A Sketch Map of Task Decomposing and Composing

Generally speaking, project managers and specialists decompose the tasks with the help of some software. In our test-bed of MG, we choose a WBS (Work Breakdown Structure) Chart to decompose the tasks, this kind of software may embed the MG seamlessly or as a third party software.

4. An application example

In this section, we take a real manufacturing task running in our MG platform to illustrate the process of TD. The task submitted by a customer is to manufacture 100 pieces of worm subassemblies in seven working days with 10,000 RMB. The manufacturing task of worm assembly is shown in Figure 5.

Figure 5. The Manufacturing Task of Worm Assembly

Firstly, searching the successful case a task bout worm subassembly, since there is not a successful case in the SCD, the system decomposes the with GPP template automatically. According to the task submitting mode (photo) and the task type (rapid prototype), the results of GPP decomposing is as follows: (1) rapid design; (2) rapid assembly; (3) rapid simulation; (4) rapid prototype. The basic steps of GPP decomposing are illustrated in Figure 6.

Figure 6. The Decomposing Step of Worm Assembly

Figure 7. Final Decomposing Results with a WBS Tool

Then the project manager uses a decomposing tool to decompose the results of GPP decomposing. Figure 7 shows the decomposing results with the help of WBS Chart Pro tool. In the figure, rapid design (Serial Number (SN) 2), rapid assembly (SN 6) and rapid prototype (SN 7) are imported from GPP results. Rapid simulation is omitted by the project manager. The manager continues to decompose and give the results:

 Rapid design: including the design of thrust ball bearing (SN 3), the design of deep channel ball bearing (SN 4) and the worm design (SN 5);

 Rapid assembly: including the worm assembly (SN 6);

 Rapid prototype: including the worm machining (SN 7).

Figure 7 also shows the name, executing sequence, days needing, the start and finish time of subtasks and some QoS constrains. Then a specialist can use the tool or other tool (Ex. MS-Project) to verify or modify the finally results.

5. Conclusion

In order to realize the manufacturing resource sharing, collaborative design and manufacturing, the MG takes the manufacturing resource as the service nodes, the core middleware and application middleware as the bridge, to form the virtual organization (VO) with the geographically distributed, heterogeneous resource. Because of the complexity of manufacturing industry, manufacturing task decomposing and resource evaluating mainly depend on managers’ and specialists’ knowledge and experiences. So the task decomposing is usually a semi-automatic way. TDM can’t form a common middleware, but an application middleware combining manufacturing characteristics. As a matter of fact, the advantages of MG don’t rest with the process automation completely, but encapsulation to

resources and uniform criterion, etc. In the paper, authors propose a task decomposing method combining automation with manpower. The method proves to be feasible in MG test-bed.

6. Acknowledgements

The authors appreciate the reviewers for their extensive and informative comments for the improvement of this manuscript. This work is supported by Shanghai Leading Academic Discipline Project, Project Number: J51501 and supported by Innovation Program of Shanghai Municipal Education Commission (Project Number: 09YZ389).

7. References

[1] Amid Khatibi Bardsiri, Marjan Kuchaki Rafsanjani, "A New Heuristic Approach Based on Load Balancing for Grid Scheduling Problem", JCIT, Vol. 7, No. 1, pp. 329 ~ 336, 2012.

[2] He Yuan, Yu Tao, Zhang Qiling, "Granularity Control and Cohesion Measurement in Manufacturing Grid Task Decomposition", JCIT, Vol. 6, No. 7, pp. 375 ~ 381, 2011.

[3] S Aiken, R., Carey, M., Carpenter, B., Foster, I., Lynch, C., Mambretti, J., Moore, R.,Strasnner, “Network Policy and Services: A Report of a Workshop on Middleware, Network Working Group, Category”, http://www.ietf.org/rfc/rfc2768.txt, 2000.

[4] Du Zhihui, Chen Yu, Liu Peng, Grid Computing, Qinghua University Press, China, 2004. [5] I.Foster, C. Kesselman, J. Nick, S.Tuecke, “The Physiology of the Grid: an Open Grid Services

Architecture for Distributed Systems Integration”, http://www.Globus.org/research/papers/ogsa.pdf, 2003-02.

[6] Nan Ren, Meng-wan Cao, “Research on the Path to Forming WBS in Cloud Manufacturing Environment”, AISS, Vol. 5, No. 6, pp. 467 ~ 475, 2013.

[7] Dr.K.Vivekanandan, D.Ramyachitra, B.Anbu, “Artificial Bee Colony Algorithm For Grid Scheduling”, JCIT, Vol. 6, No. 7, pp. 328 ~ 339, 2011.

[8] Alaa M. Riad , Ahmed E. Hassan , Qusay F. Hassan , “Design of SOA-based Grid Computing with Enterprise Service Bus”, AISS, Vol. 2, No. 1, pp. 71 ~ 82, 2010.

[9] Bing Li, A Meina Song, Junde Song, “A Distributed QoS-Constraint Task Scheduling Scheme in Cloud Computing Environment: Model and Algorithm”, AISS, Vol. 4, No. 5, pp. 283 ~ 291, 2012.