云制造：工作负载驱动的多任务调度策略

需积分: 9 182 浏览量更新于2024-07-14 收藏 3.42MB PDF 举报

"云制造中基于工作负载的多任务调度" 这篇研究论文主要探讨了云制造环境中如何有效地进行基于工作负载的多任务调度。云制造是一种新型的服务导向型商业模式，它整合了分布式的制造资源，将这些资源转化为制造服务，并通过集中管理的方式进行运营。这一模式使得多个用户可以同时向云制造平台提交他们的需求任务，请求服务。关键词包括：云制造、多任务调度以及任务工作负载。这表明文章的核心内容将围绕这三个关键领域展开。在云制造背景下，多任务调度是至关重要的，因为它涉及到如何有效地分配和协调各种制造资源以满足多个并发任务的需求。工作负载作为调度策略的重要依据，是指一个任务或系统在特定时间内的工作量，它可以包括计算量、数据处理量或者设备使用率等。通过对任务工作负载的精确分析和预测，调度算法可以更智能地决定任务的执行顺序、资源分配以及任务间的优先级，以优化整体的生产效率和响应时间。论文可能详细讨论了以下几点： 1. **工作负载模型**：建立能够反映任务特性和系统能力的工作负载模型，以便更好地理解任务对资源的需求。 2. **调度算法**：设计或分析用于多任务调度的算法，这些算法应能适应动态变化的工作负载，确保公平性、效率和任务的完成时间。 3. **资源优化**：在满足任务需求的同时，考虑如何最大化资源利用率，减少空闲时间和能源消耗。 4. **并发与并行处理**：探讨如何利用云环境的分布式特性，进行任务的并发和并行处理，以提高整体系统性能。 5. **动态调整**：面对工作负载的不确定性，调度策略需要具备动态调整的能力，以应对突然增加或减少的任务需求。 6. **性能评估**：可能包括对所提调度策略的仿真或实证研究，以评估其在不同场景下的性能，比如吞吐量、延迟、资源利用率和服务质量（QoS）。通过这样的调度策略，云制造平台能够有效地管理复杂的制造服务，提供高效、灵活的生产解决方案，同时降低用户的等待时间，提升客户满意度。这项研究对于推动智能制造的发展，实现制造业的数字化和智能化转型具有重要意义。

(Table 4). After task composition, the cloud manufacturing platform

will schedule these tasks onto the services (as in the context of cloud

manufacturing) oﬀered by the 10 enterprises mentioned above. Each

task has a speciﬁc workload, which can be expressed as the product of

resource eﬃciency and required completion time for a unit resource.

For instance, Milling-1/2/10 in Table 1 indicates that the operation

needs 1 unit milling equipment resource with the eﬃciency of 2 parts

per day to work for 10 days. There are constraints on task execution in

terms of time, cost, and reliability (reliability is measured by pass-rate)

(the last column of Table 4). For instance, 15/5K/0.96 means that the

task is required to be ﬁnished within 15 days with less than 5000USD

and the pass-rate should not be below 96%. Each task has a ﬁxed

subtask execution ﬂow (i.e. subtask structure). Fig. 1 shows the subtask

execution ﬂow of all tasks shown in Table 3. It should be noted that

some subtasks of these tasks are identical and thus require the same

resources.

In this example, an important issue is how to schedule these tasks

with diﬀerent workloads onto the services to better satisfy users’

requirements and achieve better system performance such as a shorter

makespan and higher service utilization. This is indeed a multi-task

scheduling problem. Solving this problem requires the establishment of

a suitable model.

4. A multi-task scheduling model

4.1. Enterprises and services

Assume that there are

registered enterprises in the current cloud

manufacturing system, which are denoted by

nt I E E E( )={ , …, ,…, }

iI1

(Fig. 2). Enterprise

(

iI1≤ ≤

)oﬀers

(

lJ1≤ ≤

)diﬀerent types of

manufacturing services (such as design services, production services,

and processing services), which are selected randomly from total

types of services in the entire cloud manufacturing system. The

(

sl1≤ ≤

) type of service is denoted by

is,

. The following attributes of

is,

, including type

, quantity

is,

, unit cost

is,

,eﬃciency coeﬃcient

, and reliability

Rel

, are taken into account. The introduction of

eﬃciency coeﬃcient

is motivated by the fact that diﬀerent enter-

prises may have diﬀerent eﬃciencies in fulﬁlling a task (or subtask)

with the same type of resource, which means that they may need

diﬀerent amounts of time for fulﬁlling the same task (or subtask) even

using the same type and the same amount of manufacturing resources

[15,16]. For example, the eﬃciencies of the lathing resources provided

by Dengyun, Honda, Shili, and Huafeng are 5, 3, 6, and 6 parts per day,

respectively. The average eﬃciency is thus 5 parts per day. Hence, the

eﬃciency coeﬃcients are 1.0 (5/5), 0.6 (3/5), 1.2 (6/5), and 1.2 (6/5),

respectively. The eﬃciency of

’s services depends on many factors

such as enterprise management level, resource quality. For the sake of

simplicity but without loss of generality, we assume that all services of

an enterprise have the same eﬃciency. The quantity

along

with its eﬃciency coeﬃcient

characterizes the capacity of enterprise

with respect to

, which is deﬁned as

Cap A α=×

i,s

. The introduc-

tion of the concept of enterprise capacity facilitates the calculation of

the time required for

to complete a subtask.

4.2. Requirement tasks

Requirement tasks come from the decomposition of users’ orders.

Assume that at a time there are

tasks to be processed in the current

cloud manufacturing system, which are represented by

ask K T T T( )={ ,…, , …, }

kK1

[21,22] (Fig. 2). A task may require one type

of service or multiple diﬀerent types of services. Here, we deal with the

latter type of tasks so that

can be decomposed into

subtasks, with

the

th (

un1≤ ≤

) subtask being represented by

ku,

. Each subtask

requires a diﬀerent type of service, which is selected randomly from the

total

types of services in the entire cloud manufacturing system.

has a certain subtask structure, which is usually a combination of the

four basic structures, including sequential, parallel, selective, and

circular [28]. For simplicity and without aﬀecting the credibility of

our results, the sequential subtask structure is assumed, i.e.

’s

subtasks have a linear structure so that they are executed sequentially

[7,8].

For

ku,

, the following attributes, including the required service type

ku,

, the required service time

ku,

when using a unit service

ku,

, and the

benchmark eﬃciency coeﬃcient

, are taken into account. The

introduction of the variables above is motivated by the fact that each

subtask has a certain workload

ku,

, which will take a period of time for

its completion using a certain amount of service (of a certain type and

with a certain eﬃciency coeﬃcient) [18]. Based on the concepts

Table 2

Geographical distances between the case companies (km).

Dengyun Honda Hongtu Shili Power Hong Teo Delta Huafeng Sunspring Fenghua

Dengyun 0 355.4 245.5 272.3 20.2 126.2 55.2 10.8 19.3 170.3

Honda 355.4 0 100.2 21.5 153.9 200.2 24.5 15.4 148.9 298.1

Hongtu 245.5 100.2 0 292.6 60.2 28.7 73.2 22.2 21.1 18.4

Shili 272.3 21.5 292.6 0 113.5 175.8 178.1 301.6 156.9 279.3

Power 20.2 153.9 60.2 113.5 0 41.6 16.5 121.0 18.6 16.0

Hong Teo 126.2 200.2 28.7 175.8 41.6 0 19.6 63.1 92.4 186.2

Delta 55.2 24.5 73.2 178.1 16.5 19.6 0 16.6 48.9 32.5

Huafeng 10.8 15.4 22.2 301.6 121.0 63.1 16.6 0 102.7 64.3

Sunspring 19.3 148.9 21.1 156.9 18.6 92.4 48.9 102.7 0 136.1

Fenghua 170.3 298.1 18.4 279.3 16.0 186.2 32.5 64.3 136.1 0

Table 3

Subtask information of each task.

Task Subtask1 Subtask2 Subtask3 Subtask4 Subtask5 Subtask6

30207537 Valve Clutch housing Crankcase Oil pan Connecting rod Gear housing

30207538 EGR passage Crankcase Valve Oil pan Gear housing Connecting rod

30207540 Crankcase EGR passage Valve Clutch housing Connecting rod Gear housing

30207541 Gear housing EGR passage Valve Crankcase Valve Oil pan

30207543 Valve Crankcase Connecting rod Oil pan Gear housing EGR passage

30207568 Gear housing Clutch housing EGR passage Valve Crankcase Oil pan

30207573 Oil pan Gear housing Connecting rod Valve EGR passage Clutch housing

30201025 Crankcase Oil pan Connecting rod Valve EGR passage Clutch housing

Y. Liu et al.

Robotics and Computer–Integrated Manufacturing xx (xxxx) xxxx–xxxx

剩余17页未读，继续阅读

weixin_38684633

粉丝: 4
资源: 927

云制造：工作负载驱动的多任务调度策略

云制造环境下子任务在分布式机器人中的调度方法.pdf

任务编排时，基于定时器的周期任务调度，怎样进行测试

基于hypervolume方法的云计算dag任务调度方法研究

静态负载均衡和调度算法的关系是什么

xxljob任务调度

Cloudsim实现基于多维QoS的资源调度是要通过什么来解决什么

autosar多核任务调度

任务调度期 海豚 使用教程

springboot定时任务多实例调度

spring cloud的任务调度

最新资源

任务调度期海豚使用教程