协同Agent（共4篇）
协同Agent 篇1
1 概述
近几年来,随着分布式人工智能技术、网络技术和多媒体技术的发展,人们对资源共享及分布式协作提出了更高的要求。开发基于知识的协同设计环境,以模拟和帮助人类专家进行知识和信息的处理,使产品设计过程逐渐实现自动化已成为现代工业设计的目标。Agent技术作为一个能分析、设计和实现分布式软件系统的新方法,得到了越来越多的研究者的青睐。
在多Agent系统(MAS)中,多个智能Agent体之间可以进行信息的交互,这样各智能体间就可以很方便的进行知识的共享、通信和协同工作。在计算机支持的协同设计(CSCD)系统中,各个参与者和多Agent系统中智能体具有相似的行为特征,这样我们可以参考MAS的体系结构特征来设计和实现CSCD体系结构。
一般来说,研究者主要是关于三个方面的研究:产品模型研究、一致性操作研究和系统体系结构研究。在这个领域中,斯坦福大学的Cutkosky开发了PACT,通过共享的设计模型,Agent封装了软件工具,通过Agent通信提高了应用工具的可操作性。加拿大卡尔加里大学的沈卫明提出了一个分布式智能设计环境DIDE,采用Agent技术,整合了传统的CAD/CAM工具,数据库,知识库系统等,达到协同设计的目的。
尽管Agent技术已经用于开发协同设计系统,但到目前为止,大多数研究工作还处于理论研究和试验阶段,一般都是对传统的理论进行算法探讨,很少能达到实用水平。提出了一个基于多Agent的协同设计计算模型,基于该计算模型,构建了一个基于多Agent的计算机支持协同设计系统框架原型。
2 实现基于多Agent协同设计系统体系结构用到的关键技术
2.1 Agent间的通信
Agent间的通信是基于多Agent协同设计系统研究的最重要的关键技术之一,各个Agent间的协作都是通过Agent间的通信来实现的。我们采用KQML作为Agent间的通信语言。KQML的核心为一组可扩展的行为原语,定义了可作用于Agent彼此的知识库和目标库的各种许可的操作。
2.2 Agent间冲突的消解
在基于多Agent的协同设计系统中,由于各Agent个体知识的不完备性、不相容性等问题,都可能导致Agent间各种冲突的产生。我们采用如下方法对冲突进行消解:首先对冲突进行分类,建立多层式的冲突表示模型。这个策略能够在系统执行的过程中动态的决定采取什么样的冲突消解方法。这个策略在上面计算模型中的约束管理部分有所体现。
3 构建基于多Agent的协同设计框架原型
3.1 基于多Agent的协同设计计算模型
根据协同设计系统的特征,利用多Agent技术,结合协同设计过程,根据协同设计管理的权限,我们分为四个模块类型,分别是设计项目管理、设计Agent管理、数据管理和约束管理,如图1所示。
结合产品的设计过程,详细说明这个计算模型是如何便于协同产品设计的。
设计项目管理模块负责整个项目的资源的管理和设计进度的控制,详细描述设计任务,对复杂任务进行分解,对设计任务进行总体规划。对于一个新的产品设计项目,我们要做的第一步是确定详细的设计任务。设计任务和许多因素有关,比如输入、输出、开始时间、结束时间和Agent的分配等等。为了便于高效的完成任务,我们可以把一个大的设计任务分解为多个小的任务,形成了一个设计任务树。再根据任务之间的内部联系,确定任务的开始时间和结束时间。
在规划好设计任务后,设计Agent管理将会接收分配的设计任务。根据设计任务的详细说明,每个设计Agent管理采用相应的策略,做出合理的决策,一方面满足设计任务的需要,另一方面和其他设计Agent管理进行合作。总之,该模块的主要功能是策略的选择、设计目标的分解、设计决策的制定和设计的修改。
在设计的过程中,数据管理模块负责产品的数据的版本控制、设计库的维护操作和接收相应的控制等工作。约束管理模块主要是设计依赖性管理、约束检查和冲突的消解。当设计Agent管理做出一个决策的时候,会产生一个约束检验事件,验证是否和其他的设计约束相冲突。如果有任何一个约束不一致,就会通知相应的设计Agent管理,以便于参与者能够理解做出的设计决策。
3.2 实现基于多Agent的协同设计系统体系结构框架原型
基于上述计算模型,我们构建了一个基于多Agent的协同设计体系结构。这是一个由多个智能Agent组成的网络结构框架(如图2),各个智能A-gent间可以进行协作和通信,包括项目管理A-gent、协同设计Agent、数据管理Agent、支持计算Agent、通信Agent和Agent管理者。整个框架分四大部分,分别是应用服务器、数据服务器、客户端和其它人机交互接口。多个不同功能的智能Agent分别驻留在相应的功能体内。
项目管理Agent统筹整个项目的管理,帮助项目管理者描述设计项目、明确项目的初始化参数、把复杂任务分解成子任务、为设计Agent分配任务、为各个任务制定工作计划和跟踪整个项目流程等等。它为项目管理者提供了一个人机交互的接口,便于管理者高效的完成项目管理工作。
协同设计Agent封装了一些传统的CAD系统,设计者利用协同设计Agent间的相互合作完成设计任务。关于协同设计Agent现在已经有了一些标准,比如CORBA、DOM等;数据管理Agent负责管理产品的数据库,保证设计过程中的数据一致性;支持计算Agent负责解决工程计算和数据分析问题。它可以是一个有限元分析工具;通信Agent为设计者之间的信息交互提供支持,比如E-mail、视频会议、文件传输服务、应用程序共享、电子白版,SNMP等;Agent管理者管理所有其他Agent,为其它Agent提供运行环境,控制它们的可用性等等。
所有的软件Agent都是通过LAN连接并通信的。我们采用JADE(Java Agent DEvelopment Framework)作为我们的开发平台。JADE是一个完全用JAVA语言开发实现的软件框架,并采用中间件技术简化了多Agent系统的实现,并且符合FI-PA规范。我们搭建的网络环境是多台个人电脑,操作系统为windows2003,一台服务器,操作系统为Linux,数据库是My SQL。
4 结论和未来的工作。
讨论了基于多Agent的协同设计技术的特点,设计了一个协同设计系统的计算模型,基于此计算模型,实现了基于多Agent的协同设计系统体系结构框架原型。
该框架还有待于进一步探讨和完善,如多A-gent间通信效率的提高,Agent任务分配能力的增强,异常处理能力的改善等。在以后的工作中,我们将引入面向设计的软件方法,使系统更加智能化,更好的满足产品协同设计的需要。
摘要：将多Agent技术引入到计算机支持的协同设计(CSCD)领域中来,有效地解决了设计者之间信息的共享、通信和协作问题。分析了基于多Agent的协同设计技术的特点,提出了一个基于多Agent的协同设计计算模型,利用这个计算模型和多Agent的关键技术,实现了一个基于多A-gent技术的复杂产品协同设计系统框架原型。
关键词：多Agent技术,协同设计,计算模型,系统框架
协同Agent 篇2
二、基于多Agent的协同物流系统模型
物流任务是经证实的市场机会, 随机出现、难以预测且具有明显的时效性, 是无形服务, 涉及多方面的物流专业技术, 需要多种物流资源。为使来自各物流实体的各物流资源协调一致工作, 互相配合以完成最终任务, 构造一种基于多Agent的分布式协同物流系统 (DSLS) 模型, 如图1所示。DSLS由核心物流企业 (CLC) 和地理上分散的多个协同物流企业 (SLC) 组成, 每个物流企业内部又有若干物流单元 (LU) 。CAgent代表CLC, SAgent代表SLC, CLC和SLC均由订单Agent、管理Agent、任务Agent及LUAgent i (代表第i个LU) 组成。DSLS中各物流企业是对等关系, 谁获得市场机会谁就是CLC, 负责寻找SLC, 组建新的DSLS。
DSLS由物流任务触发产生协同物流要求, SLC随时处理动态到来的物流任务。CLC在DSLS系统中承担着核心作用, 主要职责是寻找市场机会并将其转化为满足要求的任务。小型任务CLC自身完成。需要多种物流资源支持或时间紧物流量大的任务需要多个SLC合作, 此时CLC寻找满足要求的SLC, 直至各任务均被SLC承诺承担。SLC在DSLS系统中扮演着分承包人的角色, 它一方面向CLC发出任务请求, 另一方面对CLC发出的任务进行分析, 并根据自身能力在众多任务中选择并承诺使自身效用最大的任务, 同时将所承诺的任务分配给所属的LU。
三、DSLS调度流程及DSLS中多Agent的协作
设CLC的订单Agent接收到需要由A种类型的Agent协同完成任务T, 任务Agent一方面从Facilitator的能力库及ANS中查询能完成各子任务的Agent, 另一方面向Internet发布任务。若对每一类型的子任务, 在返回的Agent列表及Internet投标者中都至少有一个Agent与其对应, 则启动多阶段协商过程。第一阶段为CLC与潜在SLC之间的协商, CLC要求潜在SLC给出子任务i的初始报价建议。CLC对该建议进行评价, 如不满意则提出反建议, 反复协商直到对子任务i的报价达成一致为止。并且, CLC与潜在SLC还商定, 如果DSLS组建成功, SLC除了获得前面协商的收益外, 还能获得额外的报酬 (收益的二次分配) 。该报酬由整个DSLS的结构及最后的整体收益决定, 此阶段只需商定一个额外报酬的分配比例。第二阶段为潜在SLC之间的多边协商, CLC依据第一阶段的协商结果, 将不同类型的Agent进行组合, 分别组成可能的联盟集合C1, C2, …, Cm。之后, CLC将所有可能的联盟Ci反馈给Ci中的Agent, 由这些Agent通过多边的协商来确定是否可组成联盟, 并将可组成联盟的企业信息反馈给CLC, 最后由CLC在这些联盟中决定由哪个联盟企业来承包任务T, 以组成DSLS。
四、DSLS运行算例分析
物流企业A接受了J市某企业的产品在K市配送的物流任务。A本身的物流水平不具备全程完成客户物流任务的能力, 因此将物流任务分为三个子任务并为每个子任务选择一个合作伙伴:子任务1是在J市内的装运及从J到K的运输, 子任务2是K市的仓储保管, 子任务3是K市的货物配送。物流作业流程由三个子任务构成, 每次物流作业流程只是起始时间、交付时间和时间计划不同, 其它相同。图4描述的是某次物流作业流程, 设该次物流任务合同金额为5万元。
该物流系统即为一个典型的DSLS, A是CLC, 负责寻找SLC。假设A将任务发布后, 除自己的LU (编号0) 外还有10个物流企业 (编号1-10) 投标, 其中3家具有运输资源, 投标任务1;3家具有仓储资源, 投标任务2;5家具有配送资源, 投标任务3。他们在标书中的属性值见表1, 表中仓储能力状况包括库存准确率、货损货差率、相关报表递交准时率, 运输/配送能力状况包括送货到达准时率、货损货差率、运输车辆备车及时率、事故率、送货单证返回及时率;违约赔偿率与欺骗赔偿率分别指承接任务时承诺的违约赔偿以及标书上指标与实际不符时的欺骗赔偿;风险值=费用* ( (1-违约赔偿率) + (1-欺骗赔偿率) ) /2) 。
假设此时Facilitator中还没有SLC, 且库存准确率、货损货差率、相关报表递交准时率、送货到达准时率、货损货差率、运输车辆备车及时率、事故率、及送货单证返回及时率的行业平均值分别为96%、3%、97%、96%、3%、95%、3%、95%。则所有投标企业均成为潜在SLC, 启动多阶段协商过程。
第一阶段为CLC与潜在SLC之间的协商。如图5所示, 以动态方式显示了Agent进行交互时的消息发送情况。右边的坐标轴给出了Agent协商时双方出价的变化曲线, 曲线的变化情况是由Agent的协商策略决定的, 如果曲线相交于某一点, 表明此次协商成功, 交点的出价就是双方都认可的价格, 否则, 表明此次协商失败。
第二阶段为潜在SLC之间的多边协商, 如图6所示, 显示的是第一阶段中协商成功的所有Agent组合中可组成联盟的Agent组合。
协商结果及子任务执行进度监控如图7所示, 此时, 每个子任务都已委派给具体的Agent, 即成功地实现了物流任务、物流资源与物流实体之间的自动匹配从而实现了DSLS的动态构建。
本文研究的协同物流系统, 采用多Agent解决物流调度, 将协同物流系统的功能用若干Agent来实现, 各Agent按照自己的目标解决局部问题, 并可以相互协调实现全局目标。这种物流调度的解决方案使协同物流系统具有一定的柔性、适应性和鲁棒性, 对各类企业的物流管理具有较强的参考价值。
摘要：本文提出了基于多Agent的协同物流系统的体系结构及调度流程;提出了DSLS中多Agent的协作, 通过组建DSLS除了实现预期收益外, 还可产生协同效益。
关键词：多Agent,协同物流系统
参考文献
[1]WANYAMA T, FAR B H.A protocol for multi-agent negotiation in a group-choice decision making process[J].Journal of Network and Computer Applications, 2007, 30, (3) :1173-1195.
[2]Anthony Karageorgos, Nikolay Mehandjiev, Georg Weichhart, Alexander H.ammerle.Agent-based optimisation of logistics and production planning[J].Engineering Applications of Artificial Intelligence, 2003, 16:335-348.
[3]蒋国瑞, 王敬芝, 孙华梅, 黄梯云.供应链环境下基于库存约束的多agent协同谈判研究[J].计算机应用研究, 2008, 25, (6) :1886-1889.
协同Agent 篇3
关键词：Agent,点对点协同,KQML,ARM
1 概述
80年代实行改革开放政策, 经过几十年的发展, 工业经济发展势头更猛。但是高速发展的工业经济也带来了严重的环境污染问题。政府制定了一系列措施来保护环境, 减少环境污染, 并将环境保护作为我国的基本国策之一【1】。如何判定某个地区的环境出现污染问题, 是通过对该地区的环境检测数据分析得到的。传统的环境检测方法多数是检测人员携带检测仪器到预定地点进行数据采集, 这样的缺点就是时限性和地域性限制, 在某些不适合检测人员监测的地点无法检测数据, 也不能传送实时的环境数据。
分布式人工智能 (DAI) 技术的发展为解决分布对象之间的协调操作提供了良好的理论基础, 分布式人工智能是研究人工智能计算中的开放性和交互性, 其核心就是强调系统中计算的协调性, 它将传统的通用问题求解策略和基于知识表达的基本推理形式向面向对象混合协作的模式发展, 由集中向分布式解决发展。
本文利用分布式人工智能技术设计了基于点对点协同的环境感知Agent系统来代替检测人员检测环境数据, 解决了传统的环境检测方法的缺点, 以自动化检测来代替人工检测, 为低功耗、智能化的城市环境云计算平台提供底层支持。
2 系统架构
2.1 城市环境云计算平台结构
城市环境云计算平台以环境感知Agent为节点, 通过无线传输的方式, 将各个Agent布置在特定区域而形成的[7]。这些节点功耗低、稳定、可靠, 极少需要检测人员的干预便能长时间运行。各节点通过无线传输的方式组成网络化的城市环境云计算平台[8]。
城市环境云计算平台结构如图1所示。
2.2 环境感知Agent系统架构
环境感知Agent系统是由提供各种服务的子Agent组成的, 子Agent是实际的执行体。子Agent包括:UIA (用户界面Agent) 、MA管理Agent) 、PMA (电源管理Agent) 、DCA (数据采集Agent) 、DBMA (数据库管理Agent) 、WSA (Web服务Agent) 、CA (通信Agent) 。子Agen的层次关系如图2所示。
UIA (用户界面Agent) 通过GUI与用户交互, 用户的任务通过UIA交付给MA, MA通知下一层的相关子Agent工作来完成用户的任务。
MA (管理Agent) 是用于将UIA接收到的用户任务分类后分派给下一层的子Agent。
PMA (电源管理Agent) 是用于管理Agent的功耗, 使Agent在工作状态和挂起状态切换。
DCA (数据采集Agent) 通过Agent外接的传感器采集温度、湿度、噪声等环境信息, 并进行数模转换。
DBMA (数据库管理Agent) 用来管理Agent上数据库, 将DCA采集的环境信息数据保存到数据库中, 并向WSA提供需要的数据。
WSA (Web服务Agent) 用来向用户提供Web服务, 用户通过浏览器便可以查询Agent中的环境信息。
CA (通信Agent) 用来响应的Agent进行通信, 是Agent之间协同、托管的前提。Agent之间通过KQML语言进行交互。
2.3 Agent点对点协同
开放的多Agent系统需要解决的基本问题是Agent之间的协同, 协同的前提是发送请求的Agent如何定位提供能力的Agent。多Agent系统中的基本角色包括:请求者、中间人、提供者。中间人负责协助为请求者定位提供者。中间人模型包括黑板模型 (blackboard) 、媒介模型 (matchmaker) 、经纪人模型 (broker) 。
黑板模型 (blackboard) :请求者将他们的问题投递至黑板, 提供者查询黑板中他们可以解决的问题。
媒介模型 (matchmaker) :提供者将他们的能力存储在媒介中, 请求者查询到他们需要的能力后, 直接与提供者联系。
经纪人模型 (broker) :该模型保护请求者和提供者的隐私。经纪人了解请求者的需求和提供者的能力, 为请求者找到合适的提供者。请求者和提供者在一个事务中并不直接联系。
本文设计的Agent系统使用媒介模型 (matchmaker) , 单个Agent同时扮演请求者、提供者、媒介。例如一个Agent需要提供者的服务, 并为其他Agent提供服务。服务者在媒介中注册他们的服务, 如果这些服务改变了或者服务者退出Agent系统, 媒介注销提供者的注册。媒介将提供者的能力、网络位置存储在本地数据库中。请求者需要某种服务时, 请求者先生成一个元查询, 元查询请求媒介返回一组匹配的提供者, 然后请求者根据自己的喜好选择最合适的提供者。特别是当某一种查询经常发生时, 媒介将匹配该查询的提供者的信息保存在本地缓存中, 当查询再一次发生时, 媒介直接从缓存中取出提供者信息。
2.3.1 Agent搜索算法
本文给出以下有关定义:
系统中所有Agent的集合A={a1, a2, a3, …, an}, n为系统中Agent的个数。
系统中Agent的剩余可运行时间ST={st1, st2, st3, stn}, Agent的剩余可运行时间由系统电量决定。
系统中Agent的剩余存储容量SM={sm1, sm2, sm3, smn}, Agent的剩余存储容量由系统内存容量和数据库容量共同决定。
系统中Agent之间的响应时间RT={rt1, 2, rt1, 3, rt1, n}, Agent以周期性广播的形式探测周围的Agent, 得到回复的时间即是响应时间。
在每一个Agent中维护一张2维的表格Trust_Table.如图3所示, 行代表其他Agent, 列代表Agent的属性, 例如ST、SM、RT。Agent定期检查更新该表, 当Agent需要协同服务时, 便从该表中查询到合适的Agent。
2.3.2 Agent数据托管
环境感知Agent是部署在特定区域中, 极少需要人为干预, 因此当发生系统故障时Agent应当有能力将数据托管到其他Agent上。知识查询与处理语言KQML是由美国国家研究计划署 (APPA) 提出的知识共享计划 (Knowledge Shareing Effort, KSE) 的一部分。KQML作为一种信息格式和信息处理的协议, 主要用于各Agent之间知识实时共享和行为协调, 为Agent之间和其他信息服务器和客户之间提供了一种语言规范。Agent数据托管的流程如下:
1) Agent M检测电池容量低于某一个下限, 将正在执行的进程挂起或终止。
2) Agent M查询自身的TRUST_TABLE, 根据推理公式1, 得到最合适的托管Agent N
3) Agemt M与Agent N建立连接, 并绑定。
4) Agent M与Agent N之间数据传递
5) Agent M与Agent N解除绑定后, Agent M将自身当前进程的数据保存后关闭系统。
2.3.3 系统实现
本文设计的环境感知Agent系统的硬件载体使用韩国三星公司基于ARM9的微控制器s3c2440AL芯片。该芯片是基于ARM9架构, 通过提高增加时钟频率和减少指令周期, 可以达到2倍以上ARM7的的处理能力, 功耗更低, 性能更强。该芯片采用5级流水线, 相对于ARM7的3级流水线, 提高了时钟频率和并行处理能力。操作系统选用linux2.6.30内核, 通过对其编译配置, 使其支持ARM9体系, 并精简内核。Linux需要根文件系统的支持, 用于提供系统运行的数据环境, 本系统采用YAFFS作为根文件系统。YAFFS (Yet Another Flash File System) 文件系统是专门针对nand闪存设计的嵌入式文件系统, 适合于大容量的存储设备。系统子Agent的实现如下:
DCA (数据采集Agent) :本Agent设计为内部处理、统一接口的可替换模块化结构。各种传感器根据需要连接到模数转换采集板上, 这样可以方便用户随时裁剪和扩展系统的功能, 对应每种传感器的环境数据采集工作由驱动层的传感器数据采集驱动完成。该模块组成如图4:
PMA (电源管理Agent) :该Agent采用太阳能电池板给铅酸电池充电。电池分为主电池和备用电池以保证电池容量不足时的电源安全, 并根据主、备电池的电池容量进行主备电池的切换, 通过嵌入式linux系统内核守护进程完成全速状态和休眠状态的切换, 以达到降低系统功耗的目的。
DBMA (数据库管理Agent) :采用SQLLite作为Agent的数据库。由传感器检测到的温度湿度等数据, 经过数模转换, 存储到SQL-Lite中。该系统每一种环境信息对应数据库中一张表, 包括温度表、湿度表、噪音表等。
WSA (Web服务Agent) :本Agent采用boa服务器作为系统的web服务器。采用CGI程序作为boa服务器的后台处理程序。使用CGI+AJAX技术设计动态页面, 使用户体验度更高。
3 结束语
本文将KQML语言和多Agent协同托管机制结合在一起, 并以此为基础设计和实现了一个基于多Agent、点对点协同的环境感知系统。该系统在工作过程中, 减少了人工干预, 使环境检测的效率有了很大提高。
参考文献
[1]白义, 张晓杰.改变传统的环境监测方法建立科学的环境数据监测网的构想[J].化工环保, 2004 (S1) .
[2]彭润, 于卫红.基于Web Service与多Agent的商务智能系统[J].电脑编程技巧与维护, 2011 (12) .
[3]陈晓争, 周莉, 张轶.基于ARM Cortex的嵌入式扫频仪设计[J].通信与广播电视, 2010 (Z1) .
[4]印盼, 赵建军, 袁宏攀.基于TQ2440和Linux的触摸屏的驱动研究[J].微型机与应用, 2011 (2) .
[5]师勇.嵌入式移动数据库关键技术分析与研究[J].制造业自动化, 2012 (3) .
[6]Bo Chen, Harry H, Cheng, Joe Palen.Integrating mobile agent technology with multi-agent systems for distributed traffic detectionand management systems[J].Transportation Research Part C, 2009, 17 (1-10) .
[7]Armbrust M.Above the clouds:A berkeley view of cloud computing[C].Electrical Engineering and Computer Sciences, 2009.
协同Agent 篇4
对复杂产品进行的快速创新性研发中, 通过集成各种有效的软硬件资源对产品进行各种性能的仿真分析, 可以节省实物试验开支、缩短产品研发周期。复杂产品的多种性能指标要求对产品进行多学科的性能仿真分析, 因此需使用多种建模和仿真分析软件。如何进行多种性能仿真分析任务的过程管理和实现复杂产品研发的协同是日益突出的问题, 复杂产品多学科协同仿真平台的流程管理要满足多种仿真的实际需求, 如复杂产品从整机到各零部件的错综复杂的流程关系、多种多样的工况条件、灵活多变且可随时回退的仿真流程等。采用用于一般业务管理的流程管理方法难以满足这些需求。目前相对成熟的PDM系统, 主要着重于对产品的设计对象和设计流程的管理, 无法很方便地集成对多种性能的仿真, 除非对PDM系统进行深层次的再次开发, 否则PDM系统无法从根本上解决问题[1], 因此如何建立一个合理的完整系统模型成为研究的热点。
离散事件动态系统 (discrete event dynamic system, DEDS) 是由离散事件驱动, 并由离散事件按照一定运行规则相互作用, 导致状态演化的动态系统[2]。在逻辑层对DEDS模型进行的研究旨在逻辑时间层次研究系统事件和状态的符号序列关系, 常用的方法有形式语言、Petri网、马尔柯夫链等。基于Petri网络的仿真模型方法在DEDS研究和仿真中有着十分广泛的应用, 解决了许多实际系统的分析与设计问题。田国会等[3]从计算机集成制造系统应用的角度对Petri网方法进行了介绍和分析, 对其在离散事件动态系统中的研究进展进行了评述。苏春等[4]提出了带有决策库所的扩展着色赋时Petri网 (ECTPN) 建模方法, 并将该建模方法用于描述板材FMS的运行过程, 并对ECTPN模型中的资源冲突等问题进行了分析。
Agent及多Agent技术在仿真系统领域的应用得到了迅速发展。马保海等[5]把Agent技术引入分布式仿真平台设计。陈曦等[6]通过对Agent技术和服务技术以及虚拟样机仿真系统的研究, 提出了一种面向多领域的复杂产品虚拟样机仿真支撑平台的实现方案。
为了系统体系能适应仿真流程的复杂性和多变性, 以及仿真分析类型多样性和仿真任务分布性的要求, 笔者结合Petri网和多Agent的优点, 提出一种以流程为核心、面向复杂产品研发仿真过程的协同仿真环境 (collaborative simulation environment, CSE) [7]体系模型。
1 CSE中基于Petri网的DEDS模型
1.1Petri网的基本定义
六元组Σ= (P, T, F, K, W, M0) 构成PN (Petri net) 系统的充分必要条件如下:
N= (P, T, F) , N构成有向网, 称为Σ的基网, 其中, P为N的有限库所集, P={p1, p2, …, pn}, pi (i=0, 1, …, n) 为第i个库所;T为N的有限变迁集, T={t1, t2, …, tm}, tj (j=0, 1, …, m) 为第j个变迁;F为N的流关系, F⊆ (P×T) ∪ (T×P) , F也可表示为F={ (x, y) |∀x, y∈P∪T}, 即连接弧集合;K、W、M0依次为N上的容量函数、权函数和初始标识;用Z代表非负整数集, Z+代表正整数集, 则有①K:P→Z+∪{∞}, K (P) 表示P的最大容量;②W:F→Z+∪{∞}, W (x, y) 表示弧 (x, y) 的权值;③M:F→Z, 对∀p∈P, M (p) ≤K (p) , M (p) 表示P中的托肯数, M= (M (p1) , M (p2) , …, M (pn) ) 表示系统的一个状态。
Petri网的模型只给出了系统的静态结构及特征, 系统的动态行为是在Petri网的运行过程中体现出来的, Petri网的特性主要由可达性、避免性、有界性、活性、回归性和守恒性等性质[8]来描述。
1.2基本的PN组件模型
为了定义流程中的4种基本路由, 即顺序路由、并行路由、条件路由和循环路由, 构造了4种基本的PN组件模型与之对应, 在构造系统的PN模型时可以直接使用这些基本组件模型, 实现复杂系统的建模。
串行组件模型。串行组件模型与顺序路由相对应, 描述一系列按固定顺序串行执行的活动, 它由一条没有分支的通路组成, 如图1所示。
并行组件模型。并行组件模型与并行路由相对应, 描述可同时进行的分支活动, 在这个基本模型中需要用“与分支”和“与合并”加以描述, 如图2所示。
选择组件模型。选择组件模型与条件路由相对应, 描述彼此间有相互制约与排斥关系的分支活动, 根据具体的执行情况和条件从中选择其一, 在此基本模型中用“或分支”和“或合并”加以描述, 如图3所示。
循环组件模型。循环组件模型与循环路由相对应, 描述需要重复执行多次的活动, 如图4所示, 其中循环的执行是有条件的, 若满足循环的判断条件, 则进行循环, 否则流程向下顺序执行。
1.3CSE系统的PN模型
对CSE系统的仿真过程进行分析可知, 可把包含多种仿真任务的复杂仿真流程描述为多种层次的流程。在基本PN组件模型的基础上, 构建了CSE系统基本的PN模型, 如图5所示。
CSE系统基本的PN模型具有主流程和子流程两个层次, 子流程作为主流程中的某一活动, 主流程的输入和输出分别为子流程的输出和输入。主流程的某一活动是系统或零部件的某项仿真分析任务, 这些活动间可能存在着顺序、并行、选择和循环等关系。子流程的某一活动是系统或零部件的某项仿真分析任务中某一步的子任务, 这些活动间可能存在着顺序、并行和循环等关系。
2 基于多Agent的仿真组件模型
组件是子系统的基本组成部分或功能部件中的一个单元, 它既可以是一个独立的元件, 也可以是若干部件的组合。为了能建立可灵活定制的仿真分析流程, 基于Agent技术, 把子流程中的子任务 (活动) 抽象为通用的仿真组件模型。
2.1仿真组件的定义
把具有特定仿真功能的仿真模块抽象后所构成的组件称为仿真组件, 它由仿真组件描述和仿真组件实现组成。仿真组件描述是对仿真组件的功能和接口的描述, 这体现在CSE服务上, 它保证了CSE服务中Agent消费者 (Consumer) 对仿真组件的正确调度。仿真组件实现是对仿真软件工具或功能模块的封装, 主要定义了组件框架对组件进行管理和调度的接口, 以及组件要完成功能的内容和实现方法。
仿真组件的接口定义由若干实体类进行描述, 包括有仿真组件 (simulationComponent) 、仿真组件参数 (simulationComponentParameter) 、分析参数 (analysisParameter) 、元数据参数 (metaDataParameter) 、仿真任务 (simulationTask) 、入口点 (entryPoint) 和仿真任务参数 (simulationTaskParameter) 等。这些实体类所通过Hibernate进行映射, 转变为对应的数据库表, 实现对各种对象的数据库数据的操作, 数据库表之间的关系如图6所示。
仿真组件采用Agent的形式对具有特定仿真功能的模块进行抽象与描述, 仿真组件分为应用程序型和Web服务型。应用程序型仿真组件由三部分组成, 即Agent (代理) 、Adapter (适配器) 和Driver (驱动器) , 这类仿真组件针对CAD/CAE、自制专业求解器等应用程序。Web服务型仿真组件由Web Service构成, 这类仿真组件针对报告生成器等Web Service类型的应用。
2.2仿真组件的模型
根据上节对仿真组件定义的描述, 构建了CSE系统中基于Agent的仿真组件模型, 如图7所示。仿真组件模型由CSE仿真运行平台、CSE服务器端和CAE服务器端三部分构成。CSE仿真运行平台包括仿真流程编辑器和仿真流程执行器两个子平台, 通过仿真流程编辑器建立产品的仿真流程, 其中子流程的仿真任务是根据各仿真组件实例化生成的;通过仿真流程执行器可以进行仿真流程的控制, 仿真任务的执行驱动相应的CAE仿真软件Agent。CSE服务器端通过仿真流程引擎、Agent Consumer和仿真组件定义提供仿真组件相关的服务。CAE服务器端由多个Agent构成, 其中的Agent是由各CAE软件的适配器 (Adapter) 和驱动器 (Driver) 组成。适配器的主要功能是对仿真组件的解析及软件配置入口点的定位, 驱动器的主要功能是保证参数输入的正确并启动相应的仿真软件。
3CSE系统体系模型
3.1Petri网与Agent的融合方法
上述仿真组件是将Petri网模型和Agent融合起来的桥梁, 根据仿真组件进行实例化后的仿真任务在Petri网中以活动的身份出现, 它也是CSE系统PN模型中子流程的每个活动任务。同时, 根据仿真组件的定义可知, 仿真组件又与各种CAD/CAE仿真代理Agent相互关联。每种仿真组件通过图6所示的entryPoint类与Agent进行关联。在CSE系统的PN执行过程中, 对仿真活动任务的操作指令映射为对不同仿真组件的调用, 仿真组件通过entryPoint确保对不同的Agent实现正确的调用与管理, 从而实现Petri网模型与Agent的无缝融合。
3.2CSE系统体系结构
基于Petri网和多Agent技术的CSE系统体系结构如图8所示, 分为如下五层。
(1) 数据支撑层。
数据支撑层主要包括流程数据库、仿真数据库和仿真资源内容仓库。流程数据库主要用来存放CSE系统基于Petri网所构建的主流程和子流程相关的实体数据信息, 保证流程引擎对仿真流程信息访问的一致性;仿真数据库主要存放仿真任务的相关数据信息, 在仿真任务执行过程中进行仿真数据的实时更新;仿真资源内容仓库主要存放仿真过程中由仿真软件Agent产生的仿真模型文件和数据。
(2) 数据访问层。
数据访问层主要提供业务逻辑层对数据支撑层的访问接口和控制, 不同的逻辑业务对数据库具有不同层次的访问权限和访问方式, 通过该层进行控制以确保数据访问接口的统一和数据访问的安全。
(3) 业务逻辑层。
业务逻辑层由流程管理服务层、本地代理层和接口层组成。流程管理层基于Petri网理论进行主流程管理、子流程管理、仿真任务驱动和仿真组件解析;本地代理层基于多Agent技术对各种CAE组件进行管理, 包括CAD三维造型、机构运动学分析、结构静力学分析、多体动力学分析和气动分析等;接口层通过XML Schema把数据转换为XML格式的信息以用于系统间传输。
(4) 网络传输层。
网络传输层是网络化环境下进行数据交换的实现层, 通过SOAP/HTTP和TCP/IP协议实现网络通信和信息交换。
(5) 客户应用层。
客户应用层是多Agent层, 主要为CSE系统提供仿真软件代理。仿真软件代理为仿真组件所对应的仿真软件提供Agent注册、发布、发现和绑定等功能, 并以Web Service的方式提供统一的Agent服务。客户应用层通过XML数据接口与网络传输层交换数据。
4 应用实例
本文以Elcipse3.2为开发工具, 采用SOA (Service Oriented Architecture) 架构, 开发了应用于复杂系统的协同仿真平台, 并以某型飞机的悬挂系统为应用实例进行了验证。
4.1多层次分布式仿真流程建模
在仿真流程编辑器子平台上建立仿真流程, 流程的编辑视图由主流程编辑视图和子流程编辑视图组成, 如图9所示。主流程的活动都是由子流程组成的, 双击主流程中的某一子流程即可进入其对应的子流程编辑视图。子流程中的仿真任务是执行各种仿真软件的具体活动, 它们是仿真组件的实例, 这些任务与各种具体的仿真软件Agent相关联。
4.2多层次分布式仿真流程控制
在仿真流程执行器进行仿真流程的运行控制, 以及仿真软件Agent的调用和仿真业务操作等。主流程的控制是通过部署在服务器上的主流程引擎实现的, 主要功能有主流程的启动、停止、暂停、取消, 以及根据主流程与子流程间的关联关系, 改变子流程的可执行状态。子流程执行过程中, 通过CAE视图对CAE仿真软件Agent进行封装, 可实时更新子流程中仿真任务的状态, 更新子流程的状态, 以及仿真任务的取消、返回、回退等。图10所示为仿真流程执行器主流程的控制界面。由图10可知, 4个子流程可并行运行, 它们可以在其他客户机的仿真流程执行器上进行运行控制, 并启动子流程内的仿真任务, 调用相应CAE软件Agent, 实现仿真任务的协同。
5 结语
本文提出了一种以流程为核心, 面向复杂产品研发仿真过程的协同仿真环境体系模型。在对CSE系统流程管理中基本PN模型研究的基础上, 建立了基于Petri网的CSE离散事件动态系统模型。把基于多Agent技术的仿真组件模型作为CSE系统PN模型中流程的仿真任务的执行单元, 从而实现了两种模型的综合集成。详细介绍了CSE系统的体系模型及其运行模式, 实现了复杂产品仿真流程的建模和控制, 以及多种仿真任务的协同运行。
参考文献
[1]Joshi A A.CAE Data Management Using Tradi-tional PDM Systems[C]//2004 Proceedings of De-sign Engineering Technical Conference and Com-puters and Information in Engineering.Salt LakeCity, 2004:891-900.
[2]郑大钟, 赵千川.离散事件动态系统[M].北京:清华大学出版社, 2001.
[3]田国会, 李晓磊, 杨西侠.Petri网方法及其在离散事件动态系统研究中的应用[J].山东工业大学学报, 2000, 30 (4) :322-329.
[4]苏春, 许超, 孙庆鸿.基于扩展着色赋时Petri网的板材FMS建模及分析[J].东南大学学报 (自然科学版) , 2002, 30 (2) :89-92.
[5]马保海, 裘丽华, 王占林.机载公共设备综合管理系统分布式仿真平台的设计[J].中国机械工程, 2003, 14 (23) :2033-2037.
[6]陈曦, 王执铨, 吴慧中.复杂产品虚拟样机技术研究[J].计算机仿真, 2005, 22 (12) :132-135.
[7]王海伟, 刘更, 杨小辉, 等.机械产品协同仿真环境及其关键技术[J].计算机仿真, 2008, 25 (7) :294-297.