基于PDM协同设计任务建模与调度方法研究

wanghao

协同产品设计与开发过程是一个迭代而有序的活动过程，存在多地点、多任务、多活动交互的产品定义和形成过程。这种集成产品开发环境下动态、复杂和收敛活动任务过程的建模、分配、管理和任务调度等问题，给产品数据管理(Product DataMatnagerment,PDM)系统的开发提出了免待解决的问题。   纪丰伟等提出了基于PDM平台的任务调度技术研究，将网络计划技术和专家系统的思想引入PDM系统进行智能化的任务调度。吴丹等提出基于协同服务平台的分布式产品数据管理，主要针对异地产品设计与制造环境下的PDM系统的数据交换、共享和过程协同。罗仲等遵循项目管理的思想构建了一个基于项目管理的PDM系统的设计与实现的框架。Reddy运用Petri网和遗传算法给出了约束条件下的项目调度，以实现多模式、多资源约束的项目调度。
   本文从协同设计过程中任务建模与分配、任务管理以及任务调度的角度出发，提出基于产品结构分解的多代理任务调度;在支持分布式协同设计开发环境的PDM系统内，建立产品结构与任务约束结构的人员任务分配机制、可扩展着色Petri网的任务过程建模方法，以及Multi-agent系统的任务管理和任务调度。
  1、人员一任务分配机制    1.1协同过程和过程任务分析
   在网络化协同设计过程中，将设计过程分为:实际过程和虚拟过程。所谓实际过程是指主企业所属的并负责实施和完成的过程;虚拟过程是属于伙伴企业的，由伙伴企业控制、实施和完成的过程。在协同设计过程生命周期内，实际过程和虚拟过程的递归组合也就是产品定义和形成过程。将任务划分为4种类型:单元任务，团队任务，虚拟任务，协同任务。单元任务是指由主企业中的某个人来执行的任务;团队任务是指主企业中的一个团队来执行的任务;虚拟任务是指活动过程的所有者“外包”，由一个或多个联盟伙伴来实施、完成的任务(任务可能不止一个);协同任务是指由活动过程的所有者(主企业或者伙伴企业)以与其他联盟伙伴协作的方式来完成的任务。由于协同任务涉及到联盟伙伴的参与，整个过程实质上也是实际过程和虚拟过程的迭代组合。因此，从项目管理的角度考虑可以将协同任务视为“子项目”。
    1.2产品结构与任务结构映射
    网络协同设计过程中，以产品树状结构模式为基础，以其层次化、网络特性构建基于产品结构树的协同设计过程任务分配结构，将协同过程任务显式地表现在类似产品结构的树状结构中，建立逐层、逐级的协同设计过程任务分配与管理体系结构，如图1所示。

   考虑到协同设计过程是一个动态、多目标的优化与集成过程，协同设计过程任务体系的构建受到协同过程自身、产品开发需求等诸多约束因素的影响。约束目标的优化过程，也是任务映射结构优化的过程，通过该过程可建立优化的产品结构约束的任务结构。为此，建立基于产品结构树构建任务结构树的功能映射的束模型为:
    M=f(c,s,E,P,C,O,R)………………(1)
    式中:‘为协同过程产品设计的目标;s为企业产品开发战略;;E为环境因素对产品开发的影响为产品开发的实现过程;C为协同过程中祸合问题求解的方式;o为产品结构本体和任务结构本体各自的建模方式;R为企业资源约束。
  2、基于着色Petri网的任务过程建模   从产品结构模型驱动项目任务管理出发，在项目层上，将一个项目在逻辑上分解为若干个子项目(协同任务)、虚拟任务、团队任务和单元任务的时序逻辑关系组合;在任务层上，规划底层虚拟任务、团队任务和单元任务的调度和管理，从而实现分层模块化的项目任务规划、调度、管理和监控。
   基于着色Petri网对整个协同设计活动过程建立层次化、结构化的任务调度模型。考虑到实际项目执行过程中存在分布性与并行性，需要对着色Petri网在图形符号和功能上进行必要的扩展，使得协同过程任务调度建模更为直观、清晰、合理，如图2所示。图Z中，圆形库所代表任务的开始或结束，变迁代表任务。这里，添加了另外2类库所，同心圆库所(图2中p2)代表该节点为一个决策节点，在项目实际进行过程中，由该节点触发的多个变迁中(图2中t2,,t22)有且仅有一个变迁被使能;椭圆库所(图2中p3)表示将要触发一个任务集合变迁(图2中t3)，该任务集合又可以用一个Petri网描述。在图2中，任务集t3代表产品组件或部件的设计，可以是团队任务、协同任务和虚拟任务，但不可能是单元任务。

    协同设计过程中可能存在多个并行执行的任务流，任务流之间可能存在任务间的相关性。因此，需要建立任务之间的相关性，从而实现着色Petri网项目建模的实时性。对于单元任务与团队任务、虚拟任务、子项目(协同任务)间的相关性，定义如下:
    向前相关:用Forward(t1,t2,D)表示，任务t1必须在任务t2之前完成，其中，D为时间间隔。
    向后相关:用Backward(t1,t2,D)表示，任务t1必须在任务t2之后完成，其中，D为时间间隔。
    互斥相关:用Mutual_exclusion(t1,t2,D)=For-ward(t1,t2,D)ORForward(t2,t1,D)表示，任务，1必须在任务t2之前完成，或者任务t2必须在任务且之前完成，其中，D为时间间隔。
    循环相关:用Circulation(t1,t2,T,D;)表示，任务a2与任务i之间存在循环，其中，T代表循环次数，D.表示第i次循环的时间间隔。
  3、基于Multi-agent的任务调度    3.1任务管理系统Agent分类
    根据系统的功能需求分析，从软件工程角度建立Mufti-agent协同设计过程中任务的分配、管理与调度系统，结合PDM系统开发将协同设计过程中的A-gent分为5类。
   1)项目管理Agent:负责协同过程的发起、总体规划和管理，项目层任务的划分以及任务间关系的定义和协调;并且负责向任务管理Agent发送任务列表、任务执行的参数以及要求任务返回的结果等;同时，接受任务管理Agent在任务执行时发出的异常请求;具有项目管理总体策略和项目层任务调度等方面的知识，用Project ManagerAgent表示。
   2)任务管理Agent:接受项目管理Agent发送的任务列表、任务执行的参数等。根据项目管理Agent要求返回的结果对给定的项目层任务进行分割优化和调度，并寻找最合适的任务Agent在正确的时间发送具体任务给其执行。同时，负责与站点代理Agent协同监控任务执行异常情况的发生和协调处理。具有对项目细节管理方面的知识和具体任务调度的知识，与其他任务管理Agent、项目管理Agent之间有很好的协调关系，用TaskManagerAgent表示。

wanghao

3)任务Agent:执行任务管理Agent发送的具体任务。根据任务管理Agent给定的任务参数，最大限度地发挥自己的能力去完成任务。当发现任务负荷过重时，及时向任务管理Agent发送请求，要求其他任务Agent的参与才能按时完成任务，具有发挥自己能动性执行具体任务方面的知识，用 TaskAgent表示。

    4)站点代理Agent:负责监控整个项目的执行，实时处理任务执行中发生的冲突，并负责同任务管理A-gent和项目管理Agent通信。当有任务管理 Agent向其发出请求寻找其他任务Agent来协助完成任务时，站点代理Agent会遍历整个项目中的执行任务的任务Agento若发现某个任务 Agent的任务工作量较轻同时又具有执行该任务的知识时，站点代理Agent将在任务Agent和任务管理纯ent之间建立联系，同时通知项目管理 Agent有异常出现并告以解决策略。如果找不到合适的任务Agent，站点代理Agent将从系统外部引人一个新的任务纯en。来协同执行任务。站点代理Agent具有解决冲突、协调多种Agent执行任务以及跟踪项目运行状态等方面的知识，用SiteProxyAgent表示。

    5)通信Agent:负责2种Agent之间的同步与异步通信，起到仲裁者的作用，存在于服务器端，任何其他Agent都可以通过它实现消息的转发与路由，同时，完成消息的永久存储。用ComAgent表示。

200801181014

    基于产品结构分解驱动的集成Multi-agent协同设计过程任务服务体系框架，如图3所示;项目管理Agent、任务管理Agent、任务 Agent、站点代理Agent和通信Agent分布在以CURBA/IIOP为通信架构的PDM系统平台上，每个Agent由6个部分组成，它们分别是接口层、协调单元、执行器、任务库、知识库和日志库。接口层由接口定义语言(IDL)定义，负责实现与CORBA总线的无缝对接。协调单元实现Agent 间的交互并且把获取的任务写人任务库，通知执行器可以开始执行任务。执行器从任务库提取需要执行的任务，从知识库中抽取执行任务所需要的知识来完成任务执行，并且把整个任务执行的全过程写人日志库。任务库用来存储需要执行的任务;知识库里存储本类Agent共有的知识，包括执行任务的可用模式和任务执行失败的回滚策略、冲突及异常发生时的解决策略等。日志库记录Agent执行任务的全过程以及异常发生的详细记录。

    3.2Agent通信体系

    Agent间的通信和交互协调是协同工作的基础。为实现Multi-agent系统的协调，Agent之间将?CML作为统一的Agent通信语言;两种通信方式如下。

    1)点对点通信:两个Agent之间最直接的通信方式，如图4a所示。AgentA发送消息，AgentB接收消息，不存在任何中间环节。当属于同一个任务管理Agent的多个Agent在相互传递协同工作参数时，即当任务AgentA完成本职工作将执行结果传递给任务AgentB，任务AgentB将任务AgentA的成果作为工作初始条件时，采用此通信方式。任务管理Agent向站点代理Agent发出异常请求，站点代理Agent寻找合适的任务 Agent接交给任务管理Agent以及通知项目管理Agent异常情况和冲突的处理策略等，都采用点对点通信方式。

200801181015

    2)黑板通信:消息被张贴在Agent可以访问的黑板上。见图4b。在这种通信方式下，上层Agent把任务列表、每个任务执行的参数以及要求完成的任务目标等都写在黑板上，下层Agent读取黑板上的任务列表中的任务并取走最适合自己执行的任务，同时在黑板上写人取走任务的时间、预计任务提交的时间等。上层Agent和下层Agent是相对而言的，例如，项目管理Agent与任务管理Agent是上下层的关系，任务管理Agent与任务Agent也是上下层的关系;但不考虑项目管理Agent和任务Agent的直接上下层关系。

200801181016
  4、设计实例

    以某型号引信设计为例，验证协同设计过程中基于产品结构分解的可扩展着色Petri网任务调度方法。触发式引信部分包含的零/部件有:引信母体、保险机构、惯性击发机构、调节机构、阻火机构、运解机构、防雨机构、传爆管和隔板螺圈等，如图5所示。图5中右中部为引信设计过程的Petri网建模，根据弹丸的产品结构;在项目层将任务分解为6个，d为弹丸的总体方案设计，t2为弹体设计，t3为引信母体设计，t4为弹体结合部设计，s5为引信机构设计，t6 为防雨机构设计。任务。与任务t2存在向前相关性，任务t3必须在任务口之前完成;t5与t4存在互斥相关，任务巧与任务t3存在循环关系。由此，也可以看出任务巧在整个弹丸设计中的重要地位。任务rS包括任务t5，击发机构设计，任务t1保险机构设计，任务t3调节机构设计，任务w4阻火机构设计，任务 t5运解机构设计，任务t6防爆管设计，任务t7雷管体设计和任务t8隔板螺圈设计。任务c5的子集可扩展着色Petri网调度见图5中部;右下为击发器设计t5的监控页面。

    本文从协同设计过程任务建模、管理与任务调度出发，提出基于产品结构分解的多代理任务调度，建立了产品结构与任务分解结构功能映射约束模型，实现基于产品结构分解驱动的项目人员一任务建模。在产品结构分解的基础上，基于扩展着色Petri网实现了协同设计过程可追溯历史、可重构和可扩充的项目任务调度。运用Multi-agent系统建立了基于PDM平台实现分布协同产品设计与开发环境下的协同过程任务分解、任务管理以及任务调度等系统模块。并用实例验证了方法的可行性。