协同设计(Collaborative Design)是指在计算机的支持下，各成员围绕一个设计对象，各自承担相应部分的设计任务，并行交互地进行设计工作，最终得到符合要求的设计结果的设计^[1]。网格的出现为协同设计带来了崭新的解决思路。借助于网格研究的基础设施以及Globus联盟推出的网格既定标准GT3(Globus Toolkit 3)，可以为制造业网络设计提供极为方便的底层支撑，为快速建立一个健壮的设计平台提供保证，GMCD^[4]就是这样一个设计平台。本文将首先分析网格环境中任务调度的模型，然后基于协同设计环境的特殊性，以GMCD为框架，建立一种实用的任务调度模型。
1 网格任务调度模型
　　网格环境中资源管理" title="资源管理">资源管理结构模型有分层模型、抽象所有者模型、计算市场(经济)模型和混合模型。GMCD框架是以Globus为基础的，而Globus的资源管理结构模型则是层次的。因此，本节着重讨论分层模型中的网格调度。
1.1 网格任务调度的相关组件及功能
　　在分层的资源管理结构模型中，资源管理与调度是多级的，每个资源有自己的调度子系统，用户只需把作业提交给资源请求代理，而代理后有多少资源提供者，以及该作业分配哪个资源，对于用户来说都是透明的。资源提供者可以是单个PC机，可以是单个集群或多个集群，也可以是某个组织的一个中小型局域网。它们都有一个共同点，即都有一个管理者——局部资源管理器" title="管理器">管理器。单个PC机本身就是一个管理者；而集群和局域网，一般都有一台服务器专职管理集群/局域网中的各结点。用户作业在资源请求代理上进行一级调度，在局部资源管理器上进行二级调度，如果下面存在更多的集群或局域网，则存在三级、四级等多级调度。
　　在网格任务调度中有两个非常重要的组件，分别是资源请求代理和资源管理器，它们在任务调度过程中分别进行一级和二级(多级)调度。其他与任务调度有关的组件还有网格工作站点以及负责联系的组件^[3]：
　　(1)资源请求代理
　　它是整个网格的资源管理者，负责接收用户任务，根据其特点发送给域资源管理器，动态监视任务的运行情况，根据需要将结果提交给用户或进行再调度。主要功能有：
　　①对服务提供方提供注册功能，并对其加入和退出等动作进行控制。
　　②建立网格资源信息库并周期性地刷新，对全局资源进行统一管理和分配。
　　③接收用户提交的作业，并根据作业类型和要求(如资源的类型和数量等)形成作业调度参数。
　　④根据作业调度参数调度作业，分派资源，并随时监视作业的执行情况。
　　⑤若作业执行有误，则对其进行再调度，保证用户作业的安全运行。
　　(2)域资源管理器
　　它是域内资源管理和动态调度的中心，负责本域工作的创建、属性的收集、接收从资源请求代理提交的任务并根据其特点进行处理机的分配。主要功能有：
　　①监听从本域结点发送来的信息，建立域成员信息资料库并周期性刷新。
　　②周期性地接收由资源请求代理提交的作业，并判断其可行性，建立本域的任务队列。
　　③从任务队列中选取作业，根据提交的参数和资源情况合理地分配作业。
　　④将作业执行情况定时返回给资源请求代理，维持与上级数据库的一致性。
　　⑤监视各组员执行状况，根据情况进行作业调整(域内调整或再调度)。
　　⑥确保用户作业的安全运行，将结果通知资源请求代理并直接返还给用户。
　　(3)网格工作结点
　　它是任务执行的基本单位，一旦申请加入资源提供方，便由域资源管理器直接调度和由资源请求代理间接调度。主要功能有：
　　①向上级管理器提出申请，请求加入资源提供方。
　　②收集本结点的状态和负载信息，并周期性地提交给域资源管理器。
　　③产生服务进程，随时接收上级管理器提交的任务并执行。
　　(4)负责联系的组件
　　鉴于各实体间的联系比较多，可将其分为作业提交和资源汇报两部分。
　　①作业提交部分
　　用户向资源请求代理提交作业任务；资源请求代理根据用户参数将作业转交给域资源管理器；域资源管理器根据各结点负载情况分派作业给合适的资源工作结点，任务执行完毕后保存作业结果；域资源管理器直接将结果返回给用户。
　　②资源汇报部分
　　它完成如下任务：网格工作结点向域资源管理器提供各结点的状态和负载情况；域资源管理器将该域的负载信息汇总并送给资源请求代理供查询和管理结点；域资源管理器周期性地刷新资源请求代理中的作业状态；工作结点执行完毕。
1.2 网格任务调度的过程
　　用户利用提交程序将作业任务和要求的环境属性(如资源类型和数量等)提交给资源请求代理，资源请求代理分析环境属性形成参数文件，根据任务性质、通信状况和各资源负载情况进行粗粒度调度，寻求最佳分配方案将作业及参数文件提交给选中的域资源管理器。当域资源管理器接收到新任务或调度周期到来时，新任务被赋予任务优先级插入作业队列。守护进程从结点机列表中获取该域内所有资源负载情况，同时更新资源请求代理上全局数据库中相关的信息表。确定已经到达该域的任务的优先级，每次选取一个任务分配合适的资源。相应地，守护进程派生出相应的作业线程，周期性地监视该作业的执行状态，并向上一级(资源请求代理)汇报， 以便进行全局管理与调度(或用户查询)。当任务途中异常中断或执行性能比预期要差时，资源请求代理可进行再次调度，重新安排其他资源；而当任务完成时，资源请求代理会要求域资源管理器直接将作业结果返还给用户。
2 GMCD中的任务调度机制
　　由于网格协同设计环境的特殊性，网格协同设计环境中的任务调度模型和通用的网格调度模型相比也具有特殊性。现以GMCD构架为例，讨论网格协同设计中的任务调度机制。
　　GMCD系统体系结构由底而上可分为四层，即设计知识单元DKU(Design Knowledge Units)^[4]、网格中间件、设计中间件和应用层，如图1所示。

　　DKU及互联网络组成了GMCD的底层支持结构。DKU是Internet上的具有设计能力的组织或机构，它们在某一类产品或零部件研发上具有先进的设计技术和生产能力。在DKU内部存在设计知识数据库、局域网和设计工具(集)。它们之间通过Internet或专用高速网连通。在设计过程中，各个DKU之间具有平等关系，各自负责所获得任务的运行，相对来说是独立的。
　　用户在应用层通过Portal将任务提交给设计中间件。设计中间件将由Portal提交的设计任务分解为可以被DKU执行的子任务。分解过程如下。
　　GMCD任务分解分为两层。任务以XML(eXtensible Markup Language)文件形式被提交后，首先会由资源请求代理转交给自称能完成该任务的域，然后在域控制管理器内被首次分解，分解的原则是可执行原则。对于已经进入域控制管理器的任务，应用分解智能体根据知识库内的知识，将其分解为可以被DKU执行的任务。知识库内保留了该域内所有DKU的功能申明。域内任务分解(高层分解)的目标是把任务分解为可以被DKU执行的子任务，低层任务分解在DKU内进行，其目标是把子任务分解为可以被DKU中服务器执行的底层操作。由于设计工作的特殊性，DKU分布通常不均匀，能完成有关联或相似性设计任务的DKU通常在一个或几个域内。如果被提交的设计任务没有合适的域可以执行，则还要在高层分解之前加入一层手工分解或由资源请求代理分解。也就是说，可以把任务返还给用户，由用户根据一定的设计知识对设计任务实行手工分解，也可以由资源请求代理根据域的功能自述分解为可以被域执行的子任务。域资源管理器和DKU的关系如图2所示。

　　子任务在DKU内被重新解析为可以被服务器执行的底层任务，然后由DKU调度到各个服务器上去执行。
　　高层分解和低层分解在失败时都回溯。
　　分解后的任务由域调度器调度到合适的DKU上去执行。GMCD的任务映射分为三个层次。资源请求代理保留了每个域的功能自述副本。任务通过Portal提交后，根据域的功能自述，被转交给能完成该任务的域；然后在域内分解再由域调度器进行二次映射，二次调度的目的是把分解后的子任务映射到合适的DKU上去；在DKU内的调度是第三次映射，这次调度的目的是把解析子任务后得到的底层任务映射到合适的服务器上去。本文所关注的是第二次调度，也就是分解以后的任务如何由域调度器调度到DKU上。在第二次调度中，由于设计任务的特殊性，一组相似或相关任务通常会在一个时间段内陆续到达。
3 资源预留的引入
　　资源预留是网格系统中一个十分必要的机制，因为资源预留可以保证任务在开始执行时获得必要的资源，从而提高网格系统的QoS。因此，资源预留的提出，从一开始就得到了广泛的认可，在目前网格系统的调度模块中已经被广泛采用。在协同设计过程中，每个设计任务，特别是其中某些大任务的执行直接影响设计任务完成的时间，在本文中引入了资源预留机制，以便为其中的大任务提供动态预留资源^[5]，进而提高协同设计的效率。
　　下面讨论引入资源预留的网格协同设计任务调度模型。
　　网格协同设计任务执行的框架分为三个层次：由底而上依次为资源层、资源管理控制层和应用(用户)层。资源层是可以进行设计的实体DKU或者其他必要的资源，接受资源管理控制层的管理。应用层负责用户任务的提交和结果的反馈。资源管理控制层可以抽象为一个资源管理器，在控制管理器内设置了负责任务映射和资源预留请求的模块。
　　网格协同设计任务调度系统模型示意图如图3所示。