多智能代理（共7篇）
多智能代理 篇1
0 引言
我国电力行业实施信息化已有近20年历史,电力企业信息化已涉及到电力生产、管理、经营和社会服务等各环节,对电力市场推进发挥了积极作用。但从整体看,尚存在一些问题,如信息化建设整体性弱,资源整合和共享不足,信息机构不健全,没有形成闭环管理,信息孤岛大量存在,技术平台不统一,缺乏信息化标准,安全漏洞多等,这些问题均是当前迫切需要研究的重要课题。
企业资源规划ERP(Enterprise Resource Planning)是指建立在信息技术基础上,以系统化管理思想,为企业决策层及员工提供决策运行手段的高级管理平台与面向供应链的管理工具[1]。ERP集先进的信息技术与管理思想于一体,能及时反映企业资源调配合理程度,已逐渐成为现代电力企业在信息时代生存与发展的基石[2,3,4,5,6,7]。文献[4,5,6]详细探讨了ERP在电力企业信息化中的资源整合与优化实现问题。
Agent是对过程运行中决策或控制任务进行抽象而得到的一种具有主动行为能力的实体。多代理系统MAS (Multi-Agent System)是由多个物理分散而行为自治的Agent形成的松散耦合系统,这些Agent为共同完成某项任务而遵守规约,通过交互与合作解决超出单个Agent能力的问题,特别适用于能根据空间、时间或功能进行划分的应用问题,被公认为是构建大型复杂分布式信息处理系统的重要技术框架[7,8],并已在电力系统信息化中得到广泛应用。文献[9]提出了基于多代理的电网运行决策支持系统体系结构,并对结构、功能与决策过程进行了详细阐述。在电力系统保护与控制领域,MAS的应用近年也逐渐展开,取得了一定成果,具有工程应用价值[10,11]。文献[12]提出基于多Agent的水电站计算机监控系统体系,以期提高常规水电站监控系统的智能性、集成性、分布性和开放性,具有借鉴意义。
采用多代理理论与技术框架设计的系统在多方面具有明显优势。本文将MAS技术引入电力企业ERP系统设计中,利用Agent的自治性、智能性、适应性和交互性等特点构建基于MAS的智能ERP框架,对不同类型的Agent进行分类设计,并将此构建思路应用到四川电力营销管理系统设计中,优化整合电力营销流程中大量的信息孤岛,率先实现了智能化的省级电力营销ERP系统,显著提高了电力营销业务流程运作与决策效率。设计方案兼具理论性与工程实用性,取得了良好的社会经济效益。
1 基于多代理的ERP系统概念模型
1.1 MAS的结构与层次
根据各Agent在MAS中功能和位置,可将其分为3个层次:交互层、应用层和资源层,如图1所示。其中,交互层由接口Agent组成,主要完成系统与外界的交互工作,获取系统外部信息,将其转化为规则,以支持应用层Agent动作。应用层由协调Agent和任务Agent组成,完成电力企业各项事务,包括调度、检修、营销、生产计划等一般业务过程执行和各自及整体的决策提供,其技术关键在于如何实现业务流程动态重组和利用有限资源做出智能化决策。资源层由资源Agent组成,主要完成对系统资源的各种操作,如提取、查询、存储、修改和融合等。
1.2 基于MAS的电力企业ERP模型构建
根据MAS层次划分,可把基于多代理的电力企业ERP模型视为由4种Agent组成:协调Agent、接口Agent、任务Agent及资源Agent。电力企业中每个部门都有各自的这4种Agent,部门内部各Agent有机地组合起来实现本部门任务与对外交互功能。图2为基于多代理的ERP系统概念模型示意图。
电力企业各部门可通过协调Agent进行协作,并通过网络实现通信。接口Agent为本部门与ERP系统之间的通信工具,任务Agent和资源Agent则在各专业部门中执行具体任务。各Agent作用如下:
a.协调Agent为系统结构核心,代表营销、调度生产计划等专业部门与其他部门协调Agent通信,功能包括接受指令,向资源Agent下达指令,向任务Agent传递数据,分配任务,并接收反馈;
b.接口Agent监督任务完成情况并将结果反馈用户,功能包括在用户和协调Agent之间进行通信,对结果作出解释,为终端用户准备结果报告;
c.任务Agent在知识范围内自主进行活动,功能根据电力企业各专业部门具体任务而有所不同,功能包括从协调Agent接收数据,进行数据分析与处理,将结果反馈给协调Agent;
d.资源Agent根据协调Agent指令对本部门数据库进行操作,主要功能包括根据协调Agent的要求查询并提供所需的信息,按指令对电力企业部门内数据库进行编辑、维护、更新、挖掘等相关操作。
2 基于不同类别Agent的智能ERP框架
2.1 Agent分类设计
从具体执行单元结构看,Agent可分为意识型Agent,反应型Agent,混合型Agent,信念、愿望、意图BDI(Belief,Desire,Intention)模型[9]。根据实际业务流程,将电力企业业务逻辑对象设计成以下7类功能Agent。
a.数据资源Agent负责管理日常运行所需静态数据,为系统提供基础数据服务,包括电网调度、运行、方式、用户、检修等数据,反应型结构。
b.业务活动Agent是电力业务流程基本单位,其中,公共活动是专业部门间业务重合区,由多部门业务触发;独立活动是特有业务。业务活动Agent与数据资源Agent呈多对多关系,采用混合型结构。
c.计算分析Agent用于计算并输出用于上层分析的净化数据,可分2类:第1类内部封装电力系统静态算法和模型,为决策模块提供中间数据,如电费计算Agent、潮流计算Agent、稳定计算Agent、发电计划编制Agent等,采用反应型结构;第2类内部封装特定的、可变更的逻辑规则与评价模型,如用电客户信用Agent、绩效考核Agent、电网风险评估Agent、电力市场态势评估Agent等,设计为混合型结构。
d.系统管理Agent协调整个MAS系统,管理、维护、协同各Agent,记录标识、通信地址、职能等基本信息。由于各Agent分散于电力企业局域网不同节点上,该类Agnet采用BDI模型结构来实现。
e.协调Agent协调各Agent行为,具有业务逻辑规则库,通过调整逻辑规则来协调电力企业各部门Agent间协作、调用关系,并响应外部Agent的服务请求,和系统管理Agent一起构成了整个MAS系统核心,采用BDI模型结构来实现。
f.界面Agent包括用户和服务器系统界面,能根据用户需求自定义风格,还有一定自学习能力,可根据电力企业各部门终端用户偏好与工作习惯设置界面风格与组成,采用反应型结构。
g.接口Agent负责管理电力企业ERP系统与其他系统间的信息交互、数据同步等,定义信息交互协议与数据读写统一格式,采用反应型结构。
基于多代理的电力企业智能ERP系统中各类Agent之间的层次关系如图3所示。图中,双向箭头表示Agent间数据交换、任务配置与服务请求,单向箭头表示数据传输与任务下达。
2.2 基于多代理的省级电力企业智能ERP总体结构
经过多年电力系统信息化建设,我国省级电力企业的各主要专业部门一般都拥有具有一定水平的信息化体系,如数据采集与监控SCADA (Supervisory Control And Data Acquisition)、管理信息系统MIS(Management Information System)、能量管理系统EMS(Energy Management System)、决策支持系统DSS(Decision Support System)、综合自动化系统IAS(Integrated Automation System)、电力市场运营管理系统PMMS (Power Marketing Management System)等,但这些系统往往相互隔离或交互共享性不强,信息孤岛现象严重,阻碍电力企业生产力进一步挖掘。所提基于multi-Agent的电力企业智能ERP结构着眼改变各专业部门已有信息系统间关联关系,优化电力信息系统整体组成结构,通过增加不同类型的Agent控制模块,重组企业级数据流,增强资源共享程度,提高企业效率。
结合1.2节构建与2.2节Agent分类,提出基于多代理的省级电力企业智能ERP总体结构,财务部、调度中心、生计部、交易中心、电力物流中心、工程管理等部门均可以相同的multi-Agent结构接入ERP系统。
采用本文所提结构构建省级电力企业智能ERP有如下明显优点:
a.Agent技术全面融合了面向对象技术OOP(Object Oriented Programming)思想,通过将电力业务流程封装为具有自治性、协作性、智能性的不同类型Agent实体,简化ERP流程,使整个电力业务系统对各部门的需求变更有更好的支持;
b.基于multi-Agent的设计提高了电力ERP系统的组件化程度,为系统的后期维护及功能扩展提供了便利,也为二次开发时软件模块和代码的复用提供了方便,也有利于高层决策支持系统的集成;
c.充分利用电力企业已有信息资源,结合网构软件(Internetware)技术,在不大量增添硬件条件下构建系统,建设效率高,能迅速投入工程应用;
d.借助multi-Agent技术,电力ERP系统在智能化方面得到提高,系统业务数据粒度、人机交互模式甚至决策支持的过程均可定制;
e.Agent的引入为电力ERP系统与已有系统的融合提供了灵活性和可扩展性,可实现异构信息平台间兼容、异构数据交互与操作,提高了集成化程度。
2.3 电力营销ERP中Agent工作流程分析
以电力营销中用电申请到实现供电流程中各Agnet间通信与协调为例说明所建系统工作流程。
步骤1营销人员受理用电申请后通过接口Agent输入合同,合同管理Agent在生成一张合同之前,先向辅助决策MAS的系统管理Agent、备用Agent以及生产调度接口Agent分别发出查询请求。
步骤2辅助决策MAS的系统管理Agent收到请求后,将客户信息请求发给协调Agent,由其调用客户信息Agent,查询客户当前应收电费款、电费回收率等数据,并将结果反馈给合同管理Agent。
步骤3备用子系统通过备用接口Agent获得查询请求的详细容量、电量、网络通路等信息,转由相关MAS进行与步骤2类似的操作,最终与实时库存Agent通信,查询电网备用容量和供电通路状况,由协调Agent将结果反馈给合同管理Agent。
步骤4生产调度子系统通过调度接口Agent获得查询请求的详细容量、电量、通路信息等后,与生产计划Agent通信,查询当前电网运行计划和剩余运行能力,由协调Agent将结果反馈合同管理Agent。
步骤5合同管理Agent将3个反馈信息汇总,首先判断客户信息是否符合生成新合同要求,若否则拒绝;若相符则需根据当前备用、容量、通路、计划和供电能力计算出满足用户申请的预计时间,与合同期望完成时间比较,若冲突则拒绝并建议对合同进行调整后重新输入或报规划部门进行电网改造;若相符则直接生成用电合同,并后转计量管理Agent执行,后者通过接口Agent与备用子系统营销Agent通信,协同完成关口设置、表计安装等报装业务。
3 基于MAS的四川电力营销ERP总体设计
3.1 系统基本体系结构
结合前文所述思路,本节主要讨论基于MAS的四川电力营销ERP系统的构建设计与实现。从省级电力营销系统实现层面看,应含4个层面:1.客户服务层;2.业务处理层;3.管理监控层;4.决策支持层。各层知识应依次为上层感知,并能及时接收上层协调Agent下达的任务。职能层次分为3层:省公司应用3、4层,部分涉及1、2层相关功能;地市公司应用1、2、3层,部分第4层相关功能;基层供电单位应用1、2、3层。
ERP系统基本体系结构,见图4,方框表示multi-Agent中各模块的协调Agent,箭头表示Agent间数据交互与任务配置。
为保证层次清晰,图中只列出各功能模块的协调Agent,其完整结构应包含2.1节所述的multi-Agent体系。整个营销ERP通过决策支持层协调Agent接入总线,与调度等专业部门进行高层交互。
3.2 系统中重要业务活动Agent功能设计
在电力营销业务过程中,计量管理、电费管理与客户服务是最核心的流程,构成了电力营销ERP系统的主体,其multi-Agent构架处于业务处理层与客户服务层。在这3个multi-Agent体系中均具有多个业务活动Agent,某些业务活动Agent由于功能关联与集中性较强,设计为联接同一个接口Agent,便于与终端用户交互。具体设计如表1～4所示。
3.3 系统实现技术
Agent技术融入面向对象思想,适合采用面向对象软件进行开发。利用其继承、多态和重载能力,将由电力营销资源和商业逻辑抽象而来的Agent转化为软件Agent实体。在MAS模型基础上,将各软件Agent代码实现物理封装,如组件包(COM+)形式,得到模块化软件Agent实例。同时,遵循J2EE标准和B/S多层体系结构,利用规范的XML数据交互技术,保证系统扩展性。除系统架构支持外,构件库中数据交互均用XML规范作标准,并基于模型数据交互规范采用IEC61970/IEC61968国际标准公用信息模型CIM(Common Information Model)及扩展实现和组件接口规范CIS (Component Interface Specification)的交互支持,具有较高灵活性、扩展及外延能力。
此外,建立了嵌入Web的Applet图形化建模工具来维护基于MAS的ERP流程,并通过业务可控参数来设置和控制Agent间的任务流转及任务指派,使建立在Agent构件层基础上的应用能及时响应终端用户的需求变化。
4 四川电力营销智能ERP系统测试
为保证系统可靠运行,在投运之前对四川电力营销系统进行性能与功能测试。性能测试主要需验证在本文所提构架下系统主机在尖峰负荷时动态平衡问题。本节以电费中心计算分析Agent中的电费计算任务为例进行测试,比较了相同Agent结构下保持单进程循环处理的主机存储过程算费与应用服务器算费并发性能,测试结果如表5所示。
同时进行并发、列队、串行、多进程测试,不再赘述。该计算分析Agent性能测试结论:
a.无论Agent采用哪种算费方式,若存在大量并发Agent进程,主机负荷在高峰期都无法有效控制;
b.如将关键电费计算与审核等程序通过队列的形式在该Agent中实现,将之有序排列,按先进先出的原则执行,CPU负荷可控制在50%之内;
c.从表1中可得出相对较优的计算方式,将其在电费中心计算分析Agent电费计算任务中实现。
可以看出,将并发的电费业务,如电费计算、审核、应收数据转换等计算分析Agent进行队列,转变为串行模式,可降低整个营销系统主机负荷。同时根据万户处理时间15 min计,每工作日8h内可处理32万户电费计算、审核工作需求,能满足150万用户的工作时间和主机性能需求。
功能测试要求为:按营销实际业务对Agent模块进行功能测试,观察各Agent能否满足电力营销日常业务要求;按营销业务流程对Agent进行串行测试,测试各业务活动Agent与计算分析Agent间数据流转是否达到营销业务流程要求。主机硬件环境为IBM P650,操作系统AIX5.3,数据库Sybase 12.5.3,中间件Websphere,客户端为Dell D610。将虚拟报装、虚拟抄表、虚拟坐收等业务模拟引入营销部相应业务活动Agent,如业扩Agent、计量管理Agent、合同管理Agent等。经系统全流转运行证实,系统响应快速,各Agent工作正常,相互间数据交流与任务布置畅通,能满足营销业务自动化要求,为省级电力营销辅助决策支持提供了有力保障。
5 结语
实现已有信息孤岛资源快速、高效共享和资源优化整合,是电力企业面临的重要课题。本文立足电力企业信息资源管理,结合系统资源规划实际需要,研究了基于多代理技术的电力企业ERP系统框架和体系,并将设计思路应用到四川省电力营销系统的设计与开发中,研究了省级电力营销信息管理系统的资源整合和工程实现的关键技术难题,并成功地实现了该系统,系统在全方位测试中性能良好,取得了良好的社会效益和经济效益。下一步的工作重点将着眼于利用Agent理论将其他专业部门业务流程进行智能化整合,逐步实现完整的基于multi-Agent的电力企业ERP信息资源平台。此外,本文所提构架下的电力企业ERP的评价方法、性能指标与开发及测试标准也是未来的研究重点。
参考文献
[1]JACOBS F R,BENDOLY E.Enterprise resource planning:develop- ments and directions for operations management research[J].Eu- ropean Journal of Operational Research,2003,146(2):233-240.
[2]EHIE I C,MADSEN M.Identifying critical issues in Enterprise Resource Planning(ERP) implementation[J].Computers in In- dustry,2005,56(6):545-557.
[3]AMOAKO-GYAMPAH K K,SALAM A F.An extension of the technology acceptance model in an ERP implementation envi- ronment[J].Information and Management,2004,41(6):731-745.
[4]陈亮，姚建刚，阳晓．火电厂企业管理的ERP模式分析[J]．电力自动化设备，2003，23(2)：34-36．CHEN Liang,YAO Jiangang,YANG Xiao.Analysis of the ERP mode of enterprise management for thermal power plants[J]. Electric Power Automation Equipment,2003,23(2):34-36.
[5]冯义，刘玮，熊浩，等．发电企业作业成本通用模型研究[J]．电力(??)自动化设备，2008，28(1)：47-51．FENG Yi,LIU Wei,XIONG Hao,et al.General activity-based cost model for power generation enterprise[J].Electric Power Automation Equipment,2008,28(1):47-51.
[6]庞春江，庞会静．RBAC模型的改进及其在电力ERP权限管理中的应用[J]．电力系统自动化，2008，32(13)：49-52．PANG Chunjiang,PANG Huijing.Improvement of RBAC model and its application in the competence management of electricity ERP[J].Automation of Electric Power Systems,2008,32(13): 49-52.
[7]NWANA H S,WOOLDRIDGE M.Software Agent technologies[J]. British Telecommunications Technology,1996,14(4):16-27.
[8]WOOLDRIDGE M,JENNINGS N R.Intelligent Agents:theory and practice[J].Knowledge Engineering Review,1995,10(2):115-152.
[9]杨旭升，盛万兴，王孙安．多Agent电网运行决策支持系统体系结构研究[J]．电力系统自动化，2002，26(18)：45-49．YANG Xusheng,SHENG Wanxing,WANG Sunan.Study on multi-Agent architecture based decision support system for power system operation[J].Automation of Electric Power Systems, 2002,26(18):45-49.
[10]胡巨，杨明玉．Agent技术在超高压输电线路暂态保护中的应用[J]．电力自动化设备，2004，24(5)：69-71．HU Ju,YANG Mingyu.Application of Agent technology in transient protection for EHV transmission line[J].Electric Power Automation Equipment,2004,24(5):69-71.
[11]李来福，王芝茗，于继来，等．基于MAS的多判据分层电压紧急控制系统[J]．电力自动化设备，2006，26(5)：5-10．LI Laifu,WANG Zhiming,YU Jilai,et al.Hierarchical system with multi-criterion for voltage emergency control based on MAS[J].Electric Power Automation Equipment,2006,26(5): 5-10.
[12]黄莉，张雪松．基于多Agent的水电站计算机监控系统体系结构[J]．电力自动化设备，2008，28(3)：99-102．HUANG Li,ZHANG Xuesong.Hydropower station monitoring and control system based on multi-Agent[J].Electric Po- wer Automation Equipment.2008.28(3):99-102.
多智能代理 篇2
云存储大多采用分布式存储的方式, 具有易扩展、高可用等特点, 给数据的大规模数据存储以很大方便, 同时也是云计算的基础和支撑。但是, 云存储安全性面临的挑战给它的推广形成很大阻碍。由于云存储中的数据的所有权与管理权的分离, 只有使用技术手段使得隐私数据不被泄露而且很好地实现共享, 才能从根本上解决用户对云存储的信任问题。
解决上述问题最原始的方法是将数据加密上传到云存储平台, 使用时下载到本地再解密, 这样不仅给用户的使用带了不便, 也使得数据的共享变得困难。代理重加密的提出使得云数据的代理授权变得容易, 从而有助于实现灵活安全的云端数据共享。文献[1]首次提出了代理重加密这一概念, 并构造了基于El Gamal的双向代理重加密方案。2010 年, 楼等人提出了基于身份的门限多代理者的代理重加密方案, 他们的方案都是基于双线性对运算的, 但没有很好地处理身份与多代理重加密结合时的代理权转让。
本文提出了一种新的基于身份门限的条件代理重加密方案, 此方案能够很好地结合身份与多代理者的重加密方案, 有效地减少了密钥生成时间和管理代价, 并介绍了方案设计的原型系统, 并对原型系统和方案进行了安全性分析。
2 背景知识
此节介绍双线对的定义和判定双线性Diffie-Hellman问题
2.1 双线性对
本方案主要利用椭圆曲线上的双线性映射来实现, 这里给出双线性对的定义。
选取两个阶为p的循环群G1, GT, 其中p是一个大素数。g是G的生成元。定义一个映射。e:, 若它满足以下性质:
a.双线性:对于所有的u, v G以及a, b∈ZP。有。
b.非退化性:。
c.可计算性:对于任意的u, v∈G, 能够在一个多项式时间内计算。e (u, v) 。
则称这个映射是一个有效的双线性映射。注意到, e是对称操作, 即
3 本文方案
在门限多代理机制的基础上, 本文将构造一个新的代理重加密方案, 并给出正确性和安全性证明。设 (Setup, KG, RG, E, Re, D) 是一个代理重加密算法, 其中rk为代理重加密钥。另外, 设P= (p1, p2, ……, ps) 是用户身份, P*= (P*1, P*2, ……, P*t) 是授权人设定的组合。一般来说, 在多个代理人的情况下, 加密需要分别为每个用户生成相关的消息, 我们假设B= (B1, ……Bs) 。我们的想法是用门限共享的思想对代理重加密钥rk按P* 进行密钥分片。
方案描述
Set Up (λ) .系统参数由 (λ, p, G1, G2, e, g, z, H1, H2) 构成.其中G1, G2是阶为p的循环群, 是两个群间的双线性对;g是G1的生成元, 并定义z=e (g, g) ;H1:G2→G1和H2:是两个抗碰撞的Hash函数.
Key Gen (i) .用户Pi选择多项式 (j=0, 1, 2, n-1) .同时发布公钥pki=和私钥ski= (ai0, ai1, …, ai (n-1) ) .
RKey Gen (skA, pkB, P*) . 给定私钥skA, 公钥PkB和关键字P*= (P*1, P*2, ……, P*u) , 这里考虑的门限是 (u, v) 的情况, 并要求u<n.按如下步骤输出代理重加密钥rk;
选择n-v个随机数ki (i=1, 2, …, n-v) , 计算拉格拉日系数
计算关键字的代理密钥片 (i=1, 2, …, t) 和随机数代理密钥片.
Encrypt (pki, m) .给定pkA, 消息m, 按如下步骤输出密文CTA.
(1) 计算A==ga A0r, C=zrm, D=H2 (zr, C) .随机数.
(2) 输出
Re Encrypt (CT, rk) .给定密文CTA和重加密钥和rkAB, 按如下步骤产生公钥pkB下的密文:
(1) 判断
(2) 若满足, 输出密文CTB=, 其中
;否则输出错误符号.
事实上有.
Decrypt (CTu, sku) .给定密文CTu和私钥sku, 按如下两种方式解密:
(1) CTu为原始密文CTA (A, C, D) :检查等式是否成立:D=H2 (, C) .成立, 输出m=CZ-1, 否则输出错误符号.
(2) CTu为转换后的密文CTB (A', C, D) :检查D=H2 (, C) 是否成立.成立, 输出m=CT-1, 否则输出错误符号。
4 仿真实验
4.1 实验环境和参数
为了对文中方法进行验证, 实验环境为:处理器Inter Core2.2GHz CPU, 内存为6G, 操作系统为windows7, 虚拟机为VMware Workstations 10.0.1, 性能仿真软件为Ubuntu 10.10, 对文中的算法从用户存储空间进行计算, 并与文献[7]进行比较, 在实验中忽略数据在网络中存在的传输延迟。
4.2 性能比较
图1 描述了代理重加密过程中随着身份个数变化整体所需存储空间比较:
从图1 中可以看出, 2 种方法随着身份数目从0 到120 的增加变化过程中, 存储空间均呈增长趋势, 且前期增加较为迅速, 而后期变化比较缓慢, 文献[7]方法和文中方法的存储空间大小评价约为5.37MB和3.66MB, 显然, 文中方法更具有优越性, 具有相对较小的存储空间开销。
5 结论
本文简要地分析了楼等人基于身份的门限多代理者重加密方案, 因该方案不能很好地结合身份与多代理者, 需要新的技术设计多代理者的代理重加密方案。本文利用秘密共享机制, 构造了一个新的基于多代理者的条件代理重加密方案, 方案在随机预言机模型下证明了其安全性, 并测试其性能。该方案有效地解决了在云存储环境中密钥管理代价, 因为有效地结合身份与多代理者, 有效的减少了用户私钥产生时间和存储密钥所需代价。
摘要：为了使存储在云端的数据能够安全灵活地进行分享, 提出了一个有效的基于门限多代理的重加密方案。传统的代理重加密方案中代理者通常是指独立的个体, 而在此处代理者将是一个群体 (n个人) , 只有当其中至少t个人同时参与时, 才能进行有效地代理, 其中n, t都是用户给定的身份。
关键词：代理重加密,云存储,门限,双线性对,判定双线性Diffie-Hellman问题
参考文献
[1]Blaze M, Bleumer G, Strauss M, et al.Divertible protocols and atomic proxy cryptography[A].EUROCRYPTc 98[C].Heidelberg:Springer, 1998:127-144.
[2]Canetti R, Hobenberger S.Chosen cipertext secure proxy re-encryption//Proccedings of the 14th ACM Conference on Computer and Communications Security.Alexandria, USA, 2007:185-194
[3]Libert B, Vergnaud D.Unidirectional chosen-ciphertext secure proxy re-encryption//Proceedings of the PKC'08.Barcelona, Spain, 2008, LNCS 4929, Springer-Verlag, 2008:360-379
[4]王红兵.基于双线性配对的代理重加密的研究[D].上海:上海交通大学计算机科学与技术系, 2013.
[5]庞岩梅, 李晓东, 叶思水.基于代理重加密的云数据共享机制的研究与实现[J].南京理工大学学报, 2015, 39 (1) :84-88.
[6]蓝才会, 王彩芬.一个新的基于秘密共享的条件代理重加密方案[J].计算机学报, 2013, 36 (4) :895-902.
[7]楼圣铭, 曹珍富.基于身份的门限多代理者的代理重加密方案[J].黑龙江大学自然科学学报, 2010, 27 (2) :151-156.
基于多代理的车间作业计划研究 篇3
当今,面对竞争激烈、动态多变和订单驱动的市场,制造企业的竞争优势在于快速反应产品和需求的动态变化,而采用机群或(常规)成组技术组织生产,无法根据任务的变化动态调整,不再是实现每一次加工任务的最佳配置,影响了系统柔性和快速反应的性能,同时还造成了资源的浪费。20世纪80年代美国提出虚拟制造的概念,虚拟制造单元主要的机器共享和布局上与传统的制造单元存在差异[1]。同时在成组技术基础上的虚拟单元在计划和控制能减少机器准备时间,增强系统柔性,及时应对突变的情况[2]。而且虚拟制造单元还能有效利用企业内外部资源,提高系统生产率,通过对制造资源优化组合,可以缩短任务的完成时间,其目标就是利用不同位置的现有资源,快速、高质量、低成本地完成加工任务。因此,如何组织虚拟制造单元以及在这种组织下如何安排作业计划与调度是面临的一个问题。
随着多代理技术在先进制造系统中的应用得到迅速发展,Agent所具有的自主性、交互性、反应性等特点为解决车间任务的计划与调度问题的求解提供了一个非常有效的方法。在基于代理的计划与调度中主要有招投标的方法和非招投标的方法,而前者是代理(管理者)将任务分解为可操作的子任务,具有能力完成子任务的其他代理对这些子任务进行招投标,以满足目标函数。在基于招投标的计划与调度研究中,普遍采用都是由上层Agent(单元控制Agent等) 直接根据工序任务对设备 Agent进行招标[3,4,5,6],而设备Agent只考虑的是本工序的加工任务,忽略了整体任务的前后工序间的联系,最终产生的不一定是最优的方案。因此,本文采用面向任务的虚拟制造单元的方式来组织生产,在任务计划时考虑前后工序的约束,同时为更好地满足交货期的要求,设计推动式/拉动式的招投标策略,在确定计划方案时,不能以某个竞标资源完成单个任务最优为评定依据,而应以整个任务总体完成效益最佳为目标。
1基于招投标机制的车间任务计划模型
在车间中,虚拟制造单元是随着任务的产生而产生随任务的结束而消亡的,具有一定的生命周期。其生成针对某一个具体的生产任务,由这些加工设备不在同一位置,在逻辑上形成一个虚拟制造单元,更确切地说应该是面向任务的动态虚拟单元。本文通过任务而组建的虚拟制造单元是建立在代理的基础之上的,采用招投标的形式确定任务的加工设备而形成任务计划。主要有车间代理(shop agent)、任务管理代理(task management agent)、 任务调度代理(task scheduling agent)、虚拟单元代理(virtual cell agent)、资源管理代理(resource management agent)、资源代理(resource agent),模型如图1所示。
上述模型中,GA相当车间主任的角色,是上层生产计划的接口,主要负责任务的接收。TMA负责任务的评估与分解,确定任务的优先级,并由此形成任务对应的VCA。VCA是面向任务动态生成的,任务完成时自动解体,并且有一个由TMA赋予的优先级。根据优先级大小来启动任务招投标活动,选择完成任务所需的资源。TSA负责任务的调度,当有多个相同优先级的任务需要招标时,根据其封装的算法来确定调度结果。RMA负责车间中资源管理、配置及监控,记录其数量、位置、功能及状态等信息。RA代表车间中资源实体,主要根据自身状态对任务进行招投标。
2任务计划的招投标过程
面向任务组建的虚拟制造单元的目的就是根据生产的实时信息进行任务动态分配,任务分配的结果就相应地形成了任务的作业计划。作业计划的制定是资源代理之间相互招投标来实现的。在准时化生产下,为更好地保证任务按时交货。在考虑任务前后约束的基础上,设计了拉动式与推动式招投标策略。
定义:工件Ji的第j道工序为当前工序,则工件Ji的第j道工序之前的所有工序称为前继工序,工件Ji的第j道工序之后的所有工序称为后续工序,Ji,j-1为Jij的紧前工序,Ji,j+1为Jij的紧后工序,工件Ji的第一道工序称为首工序,最后一道工序称为尾工序。
2.1招标策略
2.1.1 拉动式招标策略
拉动式招标策略定义为:以任务的工序为正向,调度Agent根据任务的交货期或紧后工序要求的最迟完工时间etj_latest向任务工序的可用设备进行招标,由于这些机器代理只有能力完成自己的任务工序,对选择投标的机器代理,根据招标信息和自己完成该道工序所需的加工时间推算出该工序的最迟开始时间stj_latest 并将不能完成的前道任务工序向紧前工序的机器代理招标,依次循环,直至首工序完成招标活动。 尾工序的确定规则是尽可能接近交货期(因为可能会出现提前或拖期的状况),工序的最迟开始时间stj_latest通过公式(1)来计算,根据公式(2)计算紧前工序的最迟完工时间,以此对紧前工序的招标参数。在公式(2)中,tranj,j-1是设备之间的运输时间,具体由车间实际情况而定。
2.1.2 推动式招标策略
推动式招标策略定义为:调度代理首先向任务的首工序的可用资源代理发出招标信息,首工序的设备招标不给定招标参数,由资源Agent根据当前时刻确定本工序最早开始时间,并计算完成本工序的结束时间,以此作为招标参数向紧后工序招标,直至尾工序。假设紧前工序的虚任务(没有进行评标的任务)的完工时间为etj-1, 那么当前工序j可以按照公式(3)、式(4)分别计算本工序的最早开始时间和完工时间。
2.2投标策略
投标者的投标策略是由其自身的负载、资源利用状况及其所拥有的竞争者的信息和对任务的执行力共同决定的。当资源Agent收到招标信息时,首先阅读任务描述信息和任务约束信息,然后查询自身可能完成任务资源的能力表,自主决策是否投标。
拉动式投标策略如下:收到紧后工序的资源代理的招标信息的首工序资源代理,通过核定自身的能力,选择是否投标,若是投标,根据虚任务,向紧后工序的资源代理投标,以此类推,直至尾工序。最后尾工序代理向调度代理提交整个任务的投标信息,则得到该任务的所有可行的加工路线;否则,采用推动式招标。推动式投标过程与拉动式投标过程相反。
现实生产车间中,由于拉动式招标比推动式招标能更好地满足准时制生产方式(JIT)对交货期的要求,往往首先采用拉动式招标。但拉动式招标可能由于紧后工序限制了紧前工序的最迟结束时间而导致紧前工序找不到可用时间间隔,而导致招标失败,此时停止招标,同时调度Agent启动推动式招标,在该种方式中紧前工序只是向紧后工序提供了自己的结束时间,并没有限制其开始时间,因此推动式招标一定有时间段安排工序,最终一定能得到计划结果。
图2展示了拉动式招投标过程。假定将分配的零件任务有3个工序,调度Agent查询得到的完成该零件各个工序任务的可用设备均有2个,假设每个可用设备均投标的情况下,拉动式招投标过程展示图如图2。
2.3招投标过程
2.3.1 拉动式招投标步骤
Step1 根据优先级,虚拟单元代理向调度代理发出招标请求,且调度代理通过查询任务的相关可用资源后,启动拉动式招标;
Step2 尾工序的资源代理根据交货期,选择完成该工序的可用时间段,形成虚任务;计算紧前工序的最迟完工时间,并根据该时间向紧前工序的可用资源代理发出招标信息;
Step3 当前工序代理依据紧后工序的招标信息,选择自身的时间段,如果有可用时间段,则安排此虚任务;
Step4 当前工序所有代理都没有可用时间段,直接进入Step 10;否则,进入step5;
Step5 安排虚任务的资源代理计算紧前工序的最迟完工时间,依据该时间向紧前工序的资源代理招标;
Step6 当前工序为首工序对应的资源代理;否则重复step2—5;
Step7 首工序资源代理进行投标,根据自己的虚任务,向紧后工序代理投标;
Step8 当前工序代理收到紧前工序的投标信息,根据自己的虚任务,向紧后工序代理投标;否则,投标值设置为空;
Step9 当前工序为尾工序,收到紧前工序投标信息的尾工序资源代理,向调度代理提交投标信息。若所有尾工序代理收到紧前工序的投标信息否为空,则进入step10;
Step10 拉动式招标失败,启动推动式招标。
2.3.2 推动式招投标步骤
拉动式招标失败之后启动推动式招标,因此,推动式招标的步骤如下:
Step1调度代理通过查询任务的相关可用资源后,启动推动式招标;
Step2 首工序的资源代理根据当前时刻,确定本工序的最早开始时间,计算本工序的完成时间,并根据该时间向紧后工序的可用资源代理发出招标信息;
Step3 当前工序根据紧前工序的招标信息,确定本工序的最早开始时间,计算完成本工序的完成时间,并根据该时间向紧后工序的可用资源代理发出招标信息;
Step4当前工序为尾工序;否则重复step3;
Step5尾工序资源代理进行投标,根据自己的虚任务,向紧前工序代理投标;
Step6当前工序为首工序,收到紧后工序投标信息的首工序资源代理,向调度代理提交投标信息。
Step7 推动式招标结束。
3任务计划的评标函数
在车间计划与调度决策性能评价指标多是注重加工时间,随着市场需求的变化,制造企业关注的指标出现多样化,如时间指标、经济指标和性能指标。实际生产中,不同的企业,甚至同一个企业在不同的时间、不同的环境下,其目标要求往往也不同,在任务的招投标过程中车间更注重的是任务加工时间短,同时生产成本低,有较大的获利空间,因而,评标函数关系着整个系统的性能是否能达到最优。所以根据本文所研究的对象,选取了加工时间、生产成本、运输费用等因子来评价投标信息。经过推拉式招投标过程,将得到任务的可行加工路线,对资源进行评判时并不是以单个工序任务的时间、成本最小为主,而是以完成整个任务的时间、成本最小为主,在满足交货期的要求下, 采用以下公式:
加工时间Tj=tm+tw, Tj表示第j道工序的加工时间;tm表示基本加工时间;tw表示辅助时间和调整时间。加工成本Cj=cd+ch+cr, 其中,Cj表示加工成本;cd表示设备成本;ch表示人力成本;cr表示能源成本。运输费用Sj=Z1ξts。 其中,Sj表示从零件的第j-1工序的设备位置到第i到工序的设备位置所需要的运输费用。ξ表示时间相对费用的折算系数,它由车间的实际情况给出;ts表示从零件的第j-1工序的设备位置到第j工序的设备位置所需要的最短运输时间,它根据车间的时间情况给出。Z1=1,表示零件的第j-1工序的设备位置与第i工序的设备位置不在同一位置,否则为0。
由于时间和成本是不同量纲函数,α1,α3为常数,目的在于将2个不同量纲的代数表达式进行无量纲化处理,α2,α4为时间和成本的不同权系数,这需要根据具体生产要求以及车间的实际情况来确定。
4案例
为验证所提出的招投标算法的有效性,文中的任务计划招投标模型是在Windows XP操作系统中,在Visual Studio 2010和.Net Framework 4.0的开发平台下,采用面向对象的C语言结合SQL Server2005数据库技术开发而成的,实现代理间任务的招投标,以广州某精密加工厂的车间进行系统应用,该车间中共有设备11台分别编号为M1,M2,M3…M11,其中下料机2台,数控冲床3台,数控折床3台,压铆机3台,分别建立各自的机器代理,并将各个机器的现有状态存入系统数据库,在某时刻,车间将对2个任务进行分配,根据车间调度员的经验和优先级规则,对2个任务分别进行任务招标,任务的数据如表1。
经查询车间中所有机器都可用,但由于设备的的新旧情况和机型的不同,同时各个零件的加工精度、批量、交货期各不相同,导致了各道工序在其可选机床集中的加工时间并不相同。招标规则依照前面所述,2个任务的最终的投标信息如表2。
在评标中,时间和成本的权重设为0.6和0.4,α1设为2,α3设为1.5,对可行加工路线进行评定之后,2个任务最终的加工路线为M1—M3—M8—M11;M1—M4—M8—M9。任务的加工时间分别为30 min和18 min,加工成本分别为75.9元,22.1元,比不采用招投标方法,任务的加工时间缩短了4.5%,加工成本节约了3.8%。
5总结
多品种小批量的生产方式下,为提高制造系统的柔性和快速反应能力,本文采用面向任务的虚拟制造单元的方式组织生产,针对以往基于Agent的调度研究中没有考虑任务前后工序之间联系的缺点,在满足交货期要求下,采用推拉式招投标策略,在评标中采用综合指标以使整体任务完成的时间和成本最小,实现了任务的动态分配,最后以一个案例来说明该方法的有效性。
参考文献
[1] Rechard Y K,Liang F,Jiang Zhibin,et al.A multistage methodologyfor virtual cell formation oriented agile manufacturing.Int J AdvManuf Technol,2008;(36):798—810
[2] Nomden G,der Zee D J.Virtual cellular manufacturing:configuringrouting flexibility.International Journal of Production Economics,2008;112(1):439—451
[3] Li Shujuan,Li Yan,Liu Yong,et al.A GA-based NN approach formakespan estimation.Applied Mathematics and Computation,2007;185(2):1003—1014
[4] Lim M K,Zhang Z.A multi-agent system using iterative biddingmechanism to enhance manufacturing agility.Expert Systems with Ap-plications,2012;160(10):957—972
[5]黄萍,宋海生,朱金达.基于多Agent机制的制造单元调度系统的研究.现代制造技术与装备,2008;5:66—67
多代理技术辩论系统中的应用 篇4
基于代理的编程把应用程序看成是由代理组成的, 代理具有自治性、前摄性的特点, 并且代理之间可以相互进行通信, 代理的这些特性使得它们能够解决一些比较复杂的问题, 例如代理可以不需要人工参与而单独地完成特定的任务。同时, 由于代理之间可以通信交流, 这样多个代理就可以联合起来以实现特定的目标, 由于以上优点, 代理技术现在得到越来越广泛的应用, 无论是相对较小的个人助理系统还是大型复杂的商业应用, 例如控制系统、系统诊断、制造业、交通、后勤、以及网络管理等。本文将代理技术应用于辩论系统中, 是对解决构建辩论系统问题方法的一个发展。
1 代理及结构
1.1 代理
代理, 又可称为软件代理[1], Wooldridge等把代理定义为具有自治性、社会性和反应性特点的软件系统[2], 代理是一种特殊的软件组件, 代理软件系统一般需要多个软件代理联合起来凭借相互影响和作用来实现, 通过多个软件代理实现的系统被称为多代理系统。
1.2 代理的结构
代理结构大致可以分为四种类型:基于逻辑的代理结构, 反应型的代理结构、BDI结构和分层的代理结构。
基于逻辑的代理结构根据传统的基于知识系统技术发展而来, 在这该结构中, 用推论机制来表示和操作符号系统。这种结构的优点是用符号来表示知识, 便于人去理解逻辑, 而它的不足之处是很难把现实世界用符号来准确地描述, 而且符号表示和操作非常地不方便, 效率低下。
反应型结构把情形和行为一一对应起来, 它是以刺激反应机制为基础的, 和基于逻辑的代理结构不同的是, 它们不使用任何复杂的符号来推理, 该结构的优点是代理在动态环境中工作效率比较高, 而且比基于逻辑的代理结构易于设计, 然而, 反应型代理仅仅依靠感应的数据有时并不能让代理选择合适的行为, 同时由于代理没有状态, 不可能让代理具有从经验学习的功能, 因而很难实现一个能够完成特定任务的代理, 尤其是在代理具有很多行为的情况下。
BDI (Belief, desire, intention) 是当前最流行的代理结构, 本文也以这种结构为基础。BDI结构的思想起源于哲学, 使用形式逻辑定义信念、愿望、意图三个心理状态, 目前有许多代理系统采用这种结构来实现, 例如JAM和JACK等, 最著名的BDI结构是过程推理系统 (PRS) [3]。该结构基于四种重要的数据结构, 即信念、愿望、意图、计划。在PRS系统中, 信念代表一个代理掌握的关于环境的信息, 目标即代表分配给代理的任务;意图代表代理已经开始着手去去完成的目标。解释器控制着这四种数据结构。最后, 它根据当前的所有意图和过程知识选择一个要开始的行为。
分层的代理结构又称混合代理结构, 该结构可分为水平分层结构和垂直分层结构。在水平分层结构中, 每一层都直接和感应输入和行为输出相联, 该结构的优点是设计简单, 对于一个需要n个不同行为的代理来说, 只要n层;它的缺点是层之间的行为可能不协调, 且层之间的交互太多。垂直分层结构解决了水平分层结构的缺点, 它只有一个输入和输出, 这种结构的主要优点是层与层之间的交互大为减少, 它的缺点是层与层之间相互依赖, 一旦某层发生问题, 整个系统便不能使用。
2 辩论系统
2.1 系统模型
辩论系统最基本的组成部分是对话模型。本辩论系统采用的对话模型以“DC”正规辩论系统模型为基础, 系统中有两个参与者, 每个参与者都有一个承诺库, 用来存放参与者说过的或接受的声明。在辩论过程中可以从承诺库中添加或删除承诺, 有一系列规则规定每个参与者的辩论时的动作, 每个参与者辩论的动作类型有声明、提问、反驳、收回和澄清, 每种动作类型描述如下:
1) 声明, 即陈述语句;
2) 提问, 对对方的声明提出问题;
3) 反驳, 对对方观点进行反问;
4) 收回, 对自己曾经的声明没有足够的论据支持, 只能收回声明;
5) 澄清, 要求对方进一步说出支持其声明的论据。
2.2 承诺规则
辩论双方都有自己的承诺库, 每个承诺库包含两种类型的列表, 即断言语句列表和让步语句列表。断言列表指的是辩论者曾明确声明过的语句列表, 让步列表指的是辩论者隐含接受的语句列表, 例如对方提出的一个声明而自己没有明确提出反对。
承诺规则如下:
1) 最初承诺, 用CR0表示:辩论双方的最初承诺都为空;
2) 收回, 用CRW表示:如果辩论某方收回自己的声明, 则该声明从它的承诺库中删除;
3) 声明, 用CRS表示:在辩论某方提出一个声明后, 如果对方之前的语句不是反驳, 则将该声明加入到自己的断言语句列表中, 同时加入对方的让步语句列表中;
4) 辩护, CRYS表示:在一个声明提出后, 如果之前对方提出的是反驳, 则将该语句加入到自己的断言语句列表中, 同时加入对方的让步语句列表中;
5) 反驳, 用CRY来表示, 对对方声明的反驳后, 如果自己的库中存在该声明, 则将该声明删除。
2.3 系统结构
本系统采用代理技术来实现, 系统有五个代理:接口代理、对话代理、承诺代理、计划代理和知识库代理。
接口代理为用户提供一个与系统交互的接口, 输入设施为用户提供输入辩论语句类型和内容的功能, 以及帮助信息等功能对话代理的组成部分:输入管理、对话管理、裁判和输出管理。输入管理为用户的输入提供支持, 它同时把输入传送给对话管理。
计划代理负责组织系统的辩论, 它根据知识库, 系统当前承诺库和对话规则的状态来产生自己的辩论语句, 是系统的“指挥者”。
承诺代理负责更新计算机和用户的承诺库, 它由一个承诺管理和两个承诺库组成, 承诺库分为系统承诺库和用户承诺库。每个承诺库都有两个声明列表, 即声明语句列表和让步语句列表, 为了区分这两类型的语句列表, 在系统运行窗口中, 我们在让步语句前加“*”号。
知识库代理有一个知识库管理和两个内容相反的知识库, 当辩论开始时, 对话管理将根据用户选择的观点让知识库代理选择一个合适的知识库以便与用户辩论, 每个知识库对应着一种计算机的论点 (观点) , 例如, 用户选择“研究生扩招是不可行的”, 计算机将选择相反的观点即“研究生扩招是可行的”, 这里知识库代理选择支持“研究生扩招是可行的”观点的知识库来与用户辩论, 反之亦然。
2.4 系统实现
实现多代理系统的平台有很多, 本文选择现在日趋成熟并且使用最为广泛的JADE平台, JADE是基于Java语言的分布式多代理开发和运行环境, 使用该平台实现多代理系统比较方便[4]。
3 结论
如何构建一个高智能的、方便使用的辩论系统是一项复杂而艰巨的任务, 多代理技术的出现为解决这个问题提供了一个有效的解决方法, 进一步工作将围绕策略的制定以及如何选择特定的辩论策略展开, 使辩论系统具有更高的智能。
摘要：辩论系统是较为复杂而难以实现的, 多代理技术又为解决复杂问题提供了一种方法。针对这种情况, 将多代理技术应用于辩论系统, 本文首先介绍了代理技术的概念及代理的结构, 然后将多代理技术应用到辩论系统中, 介绍了辩论系统的实现方法和组成部分, 最后用多代理平台JADE予以实现。
关键词：代理,辩论,多代理,对话模型
参考文献
[1]Genesereth, M.R.and Ketchpel, S.P.Software Agents[J].Communications of the ACM, 1994, 37 (7) :48-53.
[2]Huber, M.JAM:A BDI-Theoretic Mobile Agent Architecture.In Proceedings of the3rd International Conference on Autonomous Agents, 1999:236-243, New York, NY.
[3]Howden, N., Ronnquist, R., Hodgson, A.and Lucas, A.JACK Intelligent Agents Summary of an Agent Infrastructure.In Proceedings of the5th International Conference on Autonomous Agents, 2001.
多智能代理 篇5
从电力负荷统计数据来看, 高峰负荷的年累计持续时间并不长, 采用增加调峰发电装机容量的方法来满足这部分高峰负荷很不经济。另外, 由于间歇式新能源自身的“不友好”特点, 其装机容量的快速增加对电力系统调节能力提出新的挑战。需求响应[1] (DR) 是指电力用户针对市场价格信号或激励机制主动改变原有电力消费模式的行为, 随着智能电网相关技术的发展, 需求响应资源参与调度运行将能成为保持电力供需平衡的更为经济的手段, 是智能电网框架下重要的互动资源[2,3,4,5]。
然而, 需求侧资源数量多、分布广, 难以直接调度。多代理系统[6]具有良好的分散自治—集中协调特性, 已在配电网故障恢复、微电网能量管理以及电网紧急控制等方面得到了广泛应用[7,8,9], 同时也为负荷参与电网运行控制提供了有效手段[10]。负荷代理 (或称负荷聚合商) 作为协调大量中小规模需求响应资源和电网调度中心的中间机构, 能够实现所管辖范围内负荷资源的分散自治, 减少与电力公司大量通信的交互, 增强电网运行的可靠性和鲁棒性。文献[11-12]建立了竞争环境下配电公司的日前市场能量获取模型。其中, 文献[11]将各配电公司之间的竞争用一个两层优化问题描述, 外层子问题以配电公司自身利润最大为决策目标, 里层子问题为考虑安全约束的能量出清优化问题。文献[12]建立了具有分布式发电与不完全信息可中断负荷选择的配电公司能量获取模型, 针对不完全信息博弈的特征, 扩展改进了协同进化算法, 并用于求解市场贝叶斯纳什均衡。文献[13]构建了基于双层优化的可入网电动汽车充放电调度模型, 上层模型通过优化电动汽车代理商在各时段的调度计划以使得研究时段内总负荷水平的方差最小, 下层模型通过电动汽车代理商对其所管辖电动汽车充放电时间进行优化。文献[14]利用多代理对大用户直购电中不同类型交易者的谈判行为进行了模拟。针对上述相关研究, 可以发现以下结论。
1) 负荷代理可以是传统意义上的配电公司或政府实体, 也可是代表单一类型或多种类型负荷的第三方机构。其共同点是将大量电力终端用户聚合在一起参与电网调度, 并努力实现电网公司、负荷代理和电力终端用户各方的既定目标。已有研究多是针对单一类型负荷代理开展的研究。
2) 负荷代理通过对历史数据或竞争对手信息的学习, 能够通过策略性报价实现自身利润的最大化, 但不同负荷代理间存在信息不完全的可能性。
本文在上述研究的基础上, 设计了负荷代理与调度中心以及负荷代理内部响应协调机制, 发展了包含多种类型电力终端用户的负荷代理与电网调度中心的互动调度模型, 并进行了仿真验证。
1 负荷代理调度机制
负荷代理对外表现负荷群的综合外特性, 对内则协调电网调度信息和负荷群内部响应资源, 做出针对某一优化目标的最优决策。基于负荷代理的调度架构可分为3层: (1) 调度控制层, 对发用电可调度资源进行统一决策, 下发调度需求信息及调度指令; (2) 代理协调层, 将代理管辖范围内可调度负荷资源信息、报价策略等上传给调度中心, 同时将调度中心的调度指令分解成控制命令下发给负荷个体; (3) 响应本地层, 电力终端用户将自身可调度信息上传给负荷代理, 并执行代理下发的控制命令。三者间的标准输入输出接口如图1所示。
1.1 负荷代理与调度中心的互动机制
电力公司通过对发用电资源的统一调度来实现电力系统的有功功率平衡。如图2所示, 调度中心综合考虑发电侧和负荷侧资源, 以某一优化目标 (如成本最低、利润最大、接纳新能源最多等) 进行发用电资源统一优化计算。负荷代理以竞价的方式与调度中心进行互动, 竞价策略包括负荷功率调整量和相应补偿 (折扣) 价格以及功率调整的上、下限。
1.2 负荷代理内部响应协调机制
负荷代理管理着大量地理位置分散、类型各异、响应特性不同的电力用户 (如图3所示的电动汽车换电站、智能小区、商业建筑等) , 电力用户向负荷代理提供可调度负荷资源的容量、开始时间、持续时间等信息, 负荷代理通过与用户签订合同[10,15]获得部分电力终端设备的用电决策权。具体如下。
1) 代理根据内部需求响应资源特点制定多种类型的需求响应项目供电力用户选择并与用户签订合同。本文针对需求响应资源的不同响应特性, 设计了2种类型的激励型合同。合同类型Ⅰ的内容包括提前通知时间、负荷调节容量和持续时间、补偿率、折扣率等。当代理发出功率调整指令时, 签约用户按控制指令调整用电量并基于约定的补偿电价 (下调用电量) 或折扣电价 (上调用电量) 得到补偿。合同类型Ⅱ与合同类型Ⅰ的区别在于激励机制不同, 负荷代理与签约用户基于历史数据或双方协商共同形成需求价格弹性矩阵, 以此确定补偿电价 (或折扣电价) 与用电调整量的关系。负荷代理通过比较内部不同签约用户的调度成本来确定各类需求响应资源的参与数量。
2) 代理根据自身可调度资源并结合电网运行状况对电网调度中心进行策略性报价, 代理竞价成功后将基于事先签订的合同引导电力终端用户调整用电量, 负荷代理只对终端用户用电调整量进行补偿, 终端用户基线负荷仍按系统统一电价进行结算。
3) 代理具备自主学习的能力。目前, 欧美电力市场的运行一般以每天或每小时进行各类市场的投标, 并根据不同电力市场的运行规则在市场结清后公布各市场参与者的历史投标数据, 这意味着市场参与者能够根据历史运行及投标数据进行“学习”和自我优化决策, 这是多代理系统最为重要的特点之一。各代理之间进行博弈竞争, 最终引导市场趋于均衡[16]。本文也假定当多个代理同时参与电网的调度运行时, 代理通过合理猜测其他代理的不完全报价策略来进一步优化自身的报价策略。图4给出了负荷代理制定报价策略的流程图。
2 计及负荷代理的日前调度计划模型
2.1 负荷代理分散优化决策模型
2.1.1 代理报价模型
2.1.1. 1 负荷调度成本
基于本文1.2节提出的合同类型Ⅰ, 签订该类型合同的需求响应资源, 当下调或上调其用电量时, 边际成本可分别表示为:
式中:α为补偿率;β为折扣率;l0为系统统一售电电价。
签订合同类型Ⅱ的需求响应资源, 其调度成本基于合同约定的电力需求价格弹性矩阵, 补偿电价ΔlP与用电变化量ΔPP的关系如下:
式中:ε为补偿电价弹性系数;P0P为电力终端用户的基线负荷;ΔPP为签订合同类型Ⅱ的需求响应资源功率调整量;CP为调用该类型负荷的边际成本。
2.1.1. 2 代理报价策略
假设负荷代理的功率调整补偿 (折扣) 价格与功率调整量存在线性关系, 则报价策略可表示为:
式中:ljt为时段t负荷代理j上报的功率调整价格;ΔPtLdA, j为对应的负荷调整量;Ajt和Bjt为报价策略参数。
本文借鉴文献[16]提出的学习算法, 基于目前时段系统运行状态预测 (负荷预测、间歇式能源出力预测、发电机信息) , 在历史时段中搜索与目前时段最为接近的运行状态, 并将这个时段所有竞争对手的报价策略作为当前时段的猜测, 可表示为:
式中:m≠j;tn为历史上与时段t运行状态最为接近的时段;Atnm和Btnm为时段tn负荷代理m的报价策略参数; (Amt) ′和 (Bmt) ′为时段t负荷代理j对负荷代理m报价策略参数的猜测。
各负荷代理各自追求自身短期最优利润, 决策目标相互独立, 是一种非合作博弈关系。当各代理同时猜中其他代理的报价策略时, 各代理均将达到预期的最大收益, 即达到彼此接受的纳什均衡解。
2.1.1. 3 负荷代理利润
代理在向调度中心报价时, 其决策模型以自身参与调度运行的利润最大化为目标, 具体如下:
式中:T为电网调度的总时段;pILA, j为负荷代理j参与调度的利润;ΔPtLdA, P, j为时段t负荷代理j预上报的负荷调整量, ltP, j为时段t负荷代理j负荷调整的预报价, 均为报价策略参数Ajt和Bjt的函数;ΔPtEX和ΔPPt为代理内部不同类型负荷的调整量。
需考虑以下约束条件。
1) 系统功率平衡约束
式中:Ng为系统中常规发电机组的总数;NLdA为参与调度运行的负荷代理数;PtG, P, i为时段t负荷代理j根据历史数据预估的发电机组i的出力;Pttotal, 0为时段t系统基线负荷总量。
2) 代理报价上下限约束
式中:lmin和lmax分别为补偿电价下、上限约束。
3) 最大中断持续时间约束
如果电力终端设备的可中断持续时间达到用户容忍的极限, 那么该负荷必须重新接入电网。
式中:Toffline, i为负荷i从在线变为离线状态后的持续中断累积时间;TmaxoffLine, i为负荷i最大中断允许时间。
4) 最小在线持续时间约束
对于部分电力终端设备 (如空调) , 其在线持续时间必须满足用户需求。因此, 如果终端设备在线持续时间小于用户能承受的最小在线时间, 该设备必须接入电网。
式中:TonLine, i为负荷i从离线变为在线状态后的持续在线累积时间;TminonLine, i为负荷i最小在线持续时间约束。
2.1.2 负荷代理调整量内部优化决策模型
当调度中心对系统内发用电资源统一优化决策并将调度指令下发到负荷代理时, 负荷代理以最小化负荷调节成本为目标确定不同类型需求响应资源的参与数量, 具体为:
式中:ΔPEX为签订合同类型Ⅰ的需求响应资源功率调整量。
2.2 基于利润的日前调度计划决策模型
计及需求响应项目后负荷用电量的变化可能降低电力公司的收益进而影响其开展需求响应项目的积极性, 文献[17]针对这个问题提出基于利润的负荷管理模式以兼顾电力公司的利益。本文借鉴该思想, 将电网公司的利润表示为售电总收益与发用电成本之差, 因而日前调度计划决策目标可表示为:
式中:pgrid为电网售电总收益与调度总成本之差;Nw为系统中风电机组的总数;ptgrid为时段t电网售电总收益;Ctgrid为时段t电网调度常规发电机组、风电机组和负荷代理的总成本;CtG, i为时段t常规发电机组i的调度成本, 包括发电成本fG (PtG, i) 、启动成本CtG, i (1-Uit-1) Uit和备用成本fG, R (RtG, i) , 其中PtG, i为该时段发电机组i的出力, fG (PtG, i) =aiP2G, i (t) +biPG, i (t) +ci, ai, bi, ci为成本系数, ctG, i为发电机组i在时段t的启动费用系数, Uit为发电机组i在时段t的状态, 0表示停机, 1表示开机, RtG, i为发电机组i提供的备用;CtW, k为时段t风电机组k的调度成本, 由于风力发电的边际成本较低且多数享受新能源发电补贴[18,19,20], 在欧美一些风电渗透率较高的国家, 风电价格基本上是市场最低价, 本文也假设风电的调度成本较低;cWt为风电机组成本系数;PtW, k为时段t风电机组k的出力;CtLdA, j为时段t负荷代理j的调度成本;lt为时段t负荷代理功率调整的出清价格;lRt和RtLdA, j分别为负荷代理j提供的备用容量价格和容量。
约束条件如下。
1) 功率平衡约束
式中:PtG, total为时段t的机组总出力;Pttotal为时段t负荷总和;为时段t负荷代理的总调节量。
2) 负荷代理可调节容量约束
式中:分别为时段t负荷代理j可调节容量的下限和上限。
3) 系统正旋转备用约束
若系统中含有大规模间歇式新能源, 日前调度计划中还需计及由于间歇式新能源预测误差导致增加的备用, 可表示为:
式中:RtupG, i为发电机组i提供的正旋转备用;RtdLdA, j为负荷代理j提供的可下调容量;Rtup为时段t为应对负荷预测误差、机组停运和间歇式电源功率波动所需的正旋转备用需求。
4) 系统负旋转备用约束
式中:RtdG, i为发电机组i提供的负旋转备用;RtupLdA, j为负荷代理j提供的可上调容量;Rtdown为时段t为应对间歇式电源功率波动所需的负旋转备用需求。
常规发电机组的功率上下限约束、爬坡率约束等这里不再赘述。
3 算例分析
3.1 算例1
算例采用IEEE 39节点10机系统, 选取2个发电机组节点作为风电场接入点, 风电机组装机容量为3 000 MW, 结合某地区96时段 (每时段表示15min) 风电场数据和原始负荷数据进行仿真验证。仿真系统内有60%的负荷参与电网调度, 分别由2个负荷代理管理, 每个代理内部均包含1.2节所述2种类型的激励型合同, 具体参数如表1所示。
图5给出了负荷预测曲线、风电预测曲线、将风电作为负的负荷融入后的负荷曲线、同时计及风电和负荷代理功率调整的负荷曲线。从图中可以看出, 风电的“反调峰”特性拉大了负荷峰谷差, 负荷代理的融入则优化了负荷曲线。
调度中心通过对发电机组和负荷代理进行统一优化决策, 实现计及需求响应的发用电统一调度, 图6给出了负荷代理融入前后机组总出力及负荷代理的调整量。
3.1.1 电网调度成本及收益分析
图7对比了电力公司有无融入负荷代理的成本和收益, 可以得出以下结论。
1) 基于本文提出的互动调度机制, 能够促进部分需求响应资源调整用电时段, 或者在用电高峰时段 (对应风电出力较低时段) 减少用电量, 当这些需求响应资源的调用成本小于调度同样数量的发电机组成本时, 有利于电力公司降低整体的调度成本。在用电谷时段 (对应风电大发时段) 时, 由于成本中计及了向负荷代理支付的折扣电价, 使得电力公司的成本有所上升。
2) 当负荷代理参与电网调度时, 在用电谷时段, 电网公司的收益比无负荷代理时的收益要高, 这是由于本文假设风电的成本较低, 通过电网公司和负荷代理之间的良性互动促进负荷侧储能、蓄能、可转移负荷 (比如洗衣机、洗碗机) 在风电大发时多用电, 一方面有利于促进新能源的消纳, 另一方面也有利于增加电力公司的收益。在用电高峰时段 (对应风电出力较低时段) , 当负荷代理内存在部分廉价的可转移或可削减负荷时, 通过调用这些需求响应资源, 可以使得电力公司减少调度高成本的机组, 所以负荷代理的参与也有可能增加电力公司的盈利能力。
3.1.2 负荷代理收益分析
图8给出了负荷代理1和2的收益。可以看出, 负荷代理在丰富电网调度模式的同时, 基于合适的学习策略和内部分配机制, 能够通过管理内部需求响应资源并与电力公司互动来获取利润, 内部需求响应资源调度成本以及与电力公司互动时的报价策略是影响其利润的主要因素。
3.2 算例2
图9给出了某时段2个负荷代理进行30次竞价的代理收益以及电网调度成本曲线。可见, 随着竞价次数的增加, 代理不断地通过学习来优化自身的报价策略, 并最终达到非合作博弈的纳什均衡状态。另外, 随着竞价次数的增加, 系统总的调度成本有望得到降低, 市场更为有效和合理。
4 结语
多智能代理 篇6
1 空间移动网络智能代理的设计
所谓智能代理, 其实就是一种计算机程序, 其能够实现无人操控系统来完成信息接收或其他服务功能。由于空间移动网络具有节点移动性强、信息传输时延大、人工操控实现难度大、管理站与设备代理之间的操作较为频繁、极易因为占用网络带宽而降低网络效率等特点, 因此采用智能代理无疑是一种非常可行的有效控制方法。现如今在通信工程领域对于代理模块的研究多集中在多代理系统、智能代理系统、Mobile代理系统等层面。基于空间移动网络的特点, 本文提出了星载智能代理模型的概念, 即将智能代理系统设计在各个具有独立功能的航天器上, 以此来实现航天器与地面管理中心之间的通信联系, 并以此来达到管理和控制航天器的目的。具体来讲, 星载智能代理模型的设计内容主要有以下几点:
1.1 通信模块
通信模块的作用主要是为了满足智能代理系统和地面中心系统等其他外部环境系统的通信需求。其主要的设计内容是信息交换的接口设计, 采用常规的接口设计方法即可。
1.2 应用服务程序
该模块是整个智能代理的核心部分, 它包括了命令的解析和封装子模块、命令的分发子模块、安全处理子模块、对自主管理模块主动或被动的调用等。其中的安全处理子模块实现了对接收和发送报文的加密和鉴别, 从而保证了收发报文的安全性和完整性。命令/解析模块除了能够解析和封装命令报文以外, 还能够每个一段时间向管理中心发送Test原语操作, 如果发送此Test原语后, 而管理中心无响应, 则会触发自主管理模块, 通过协作子系统重新生成管理域, 并在管理域中推举出一颗管理星, 以暂时地替代管理中心对网络进行简单的网络管理和网络维护。
1.3 自主管理模块
在空间移动网络智能代理系统的自主管理模块中, 需要设置两种不同的模块, 即主动自主模块和被动自主模块。所谓主动自主模块是指智能代理在定期向地面管理中心发送Test操作原语, 若地面管理中心并没有做出相应的反应, 则该智能代理系统就会认为地面管理中心已经出现了故障或问题, 不能再继续发出操作指令。此时智能代理系统就会自动启动主动自主模块, 将某一个航天器作为暂时的管理中心来对整个空间移动网络进行管理。而被动自主模块则是在地面管理中心向智能代理系统发送了自主管理的命令后, 所进行的自主管理, 也是需要将某个航天器作为暂时的管理中心来管理整个空间移动网络。这种自主管理模块的是设置极大的提高了空间移动网络通信系统的稳定性和可靠性, 不会出现因地面管理中心故障而导致管理系统瘫痪的问题。
1.4 协作子系统
能够通过各个智能代理之间的协作, 从而构建空间环境下的空间管理域。
1.5 控制模块
用于控制仿真环境下的数据动态生成, 被管对象实例的动态更新 (如创建、删除等) 以及把控制命令转化为对设备的具体操作以及对被管对象的实时监控, 向管理进程发送告警通告, 方便管理进程进行故障分析和故障管理。
1.6 管理信息库模块
空间移动网络环境下的MIB扩展是采用MIB树中的私有对象组中定义空间信息网络环境下所需的设备对象。
2 空间移动网智能代理的实现
在开发空间移动网络智能代理系统时, 可以采用以太网作为开发环境, 在Windows操作系统平台上, 利用Eclipse 3.2 (Java集成开发环境) , SNMP4) 开源工具包进行开发和编程设计。在具体的开发和实现过程中, 可以将星载智能代理系统分为三个层次分别进行开发, 即通信层、处理层和控制层。
2.1 通信层的实现
通信层提供空天信息网星载智能代理与外部环境进行信息交流的接口。它包括空间移动网星载智能代理的通信模块、自主管理功能模块中的命令响应子模块以及控制模块中向管理进程发送通告的通告子模块。星载智能代理运行有Trap轮训程序, 用于监控运行在星上设备的状态。当星上设备发生故障或是异常时, 就会把设备发生的异常通过星载智能代理的通信层相管理站发送Trap。
2.2 处理层的实现
处理层主要是对接收到或要发送的消息进行安全处理 (鉴别或加密) ;对由代理生成并发向管理进程的通告, 生成Trap报文;对消息的封装或解析以及分发;对地面管理进程进行主动寻找并且决定是否进行协作的自治子模块;在失去管理进程管理的情况下, 由星载智能代理之间进行协作的协作子系统;在经过星载智能代理之间经过协作而形成的空间管理域后由域内管理星对域内成员进行的自主管理模块 (包括简单的故障管理和对域内成员关键设备的性能查询) 。
2.3 控制层实现
MIB访问控制层直接面向被管对象。如:被管对象实例生成和销毁, 被管对象的状态和有效值更新等, 同时接收处理层的访问请求:读取或设置被管对象属性值, 对被管对象实时监控, 向管理站发送告警通告。星上有效载荷周围的环境情况变化快, 因此需设定设备的阀值以在发生异常情况下能够及时的通知给管理站, 以及时的处理故障。
结束语
总之, 在空间移动网络的通信过程中, 可以采用智能代理的方式来提高其稳定性、安全性与可靠性, 而星载智能代理系统的开发和实现对于未来空间移动网的应用发展有着重要的意义和作用。本文只是简单介绍了星载智能代理基本功能的设计与实现, 其还有很多功能模块需要进一步的研究与开发。
参考文献
[1]闻英友, 赵建立, 王光兴.一种面向卫星综合信息网的网络管理系统[J].兵工学报, 2005 (2) .
[2]吕安杰.空间移动网络智能代理的设计与实现[D].沈阳:沈阳理工大学, 2009.
多智能代理 篇7
代理移动IPv6[1](Proxy Mobile IPv6,PMIPv6)是一种基于网络的移动性管理协议,与移动IPv6[2](Mobile Internet Protocol version 6,MIPv6)相比,PMIPv6不需要终端参与移动性管理过程,已成为支持移动互联网技术的主要协议。为提高移动互联网带宽利用率,减少网络拥塞,满足高带宽、大流量网络业务的要求,IETF(Internet Engineering Task Force)考虑在传统固定组播的基础上对移动组成员的支持,并于2009年8月成立了MULTIMOB工作组,研究基于PMIPv6的移动组播部署方案。
2011年4月,MULTIMOB工作组发布了PMIPv6域中支持组播监听者移动标准[3]RFC6224。但是,RFC6224部署机制会产成“隧道汇聚”问题,造成PMIPv6实体被迫接收冗余组播数据包。
RFC6224发布后,MULTIMOB工作组提出三种方案解决隧道汇聚问题:组播树移动锚点(Multi cast Tree Mobility Anchor,MTMA)方案[4],“直接路由”方案[4]和PMIPv6扩展方案[5]。虽然这些方案从不同角度解决了“隧道汇聚”问题,但是在设计方面仍然存在缺陷。本文提出一种基于多上游接口MLD代理的解决方案,分析方案性能,并与MULTIMOB工作组中的三种方案进行了对比。
1 隧道汇聚
RFC6224中,本地移动锚点(Local Mobility Anchor,LMA)作为移动节点(Mobile Node,MN)的组播锚点,移动接入网关(Mobile Access Gate,MAG)作为MLD代理[6](Multicast Listen Discovery Proxy,MLD-proxy),封装LMA上的组播数据使其通过PMIPv6隧道到达MAG。一个MLD代理实体可以有多个下游接口,而上游接口只能有一个。属于同一个LMA的MN接入一个MLD代理实体的下游接口,上游接口设为LMA-MAG隧道接口。MAG上虽然可以同时部署多个MLD代理实体,但是这些实体间没有交互。
如图1所示,MN1,MN2分别和LMA1和LMA2建立绑定关系,并且请求加入相同的组播组。此时组地址相同的MLD报告报文会从两个MLD代理实体的上游接口发出,分别经过Tun1和Tun2到达各自所属的LMA。LMA1和LMA2接收到组播数据之后,再经过Tun1和Tun2同时转发到MAG,此时MAG上将接收到两份相同的组播数据,造成数据冗余,即隧道汇聚问题。
2 现有移动组播方案
2.1 MTMA移动组播方案
此方案中专用实体MTMA作为组播移动锚点参与组播数据传输,与PMIPv6的单播移动性管理功能分离,MTMA部署方案如图2所示。LMA作为单播锚点传输单播数据,MTMA作为组播锚点传输组播数据。MTMA为MAG的上游组播路由器,MAG支持MLD代理功能,MTMA-MAG间的组播隧道接口设为上游接口。与图1相比,组播数据只从MTMA经过组播隧道到达MAG,进而转发给MN1和MN2,MAG并没有收到冗余的组播数据。
MTMA部署可以增强LMA的可靠性,提高PMIPv6网络的稳定性,但也有可能造成MTMA的“雪崩”问题。下面通过一个部署实例来说明该问题。假设属于不同LMA的5 000个MN同时接入一个MAG,一个LMA可以同时为50个MAG提供服务。现一个庞大的PMIPv6域有1 000 000个MN,通过计算可知至少需要4个LMA。下面设置两种组播场景:1 000 000个MN分别加入不同的组播组和相同的组播组。表1和表2分别计算了两种场景中MAG上冗余组播数据包的个数和LMA上同步到达组播数据包的个数。
通过表1,表2对比可以得出结论,当大量的MN加入相同的组播组时,MTMA方案中的MAG上没有冗余组播数据包,同时对MTMA没有造成沉重的负载压力。但一旦大量的MN同时加入不同的组播组时,本来没有“隧道汇聚”问题发生,而MTMA的管理成本却大大增加,几乎是RFC6224方案中LMA成本的4倍,导致MTMA工作效率低下。所以,随着MN数量的增加,MTMA支持组播服务的优势就会变小。
2.2 直接路由移动组播方案
此方案不需要PMIPv6隧道支持,使用MAG的本地组播设备进行传统组播通信,如图3所示。MAG上和MR(Multicast Router)相连的接口被配置为MLD代理的上游接口,组播数据沿组播树到达MAG。
当MAG和LMA的距离较远时,LMA-MAG隧道传送组播数据造成的开销可能会远远高于传统组播的开销,使用直接路由方案可以为本地组播数据传输提供最佳路由。但此方案在切换时可能会引起较大的加入延时,MTMA方案也是如此。当MN切换到一个新MAG时,不会发送未经询问的报告报文请求重新加入组播组。MLD的最大询问周期是125 s,该延时对于实际应用来说偏大,因而会造成组播服务质量低下。此外在此方案中,每个MAG只能连接一个MR,切换后的MR收到加入消息之后需要重新建立组播转发树,而原来MR1上建立的组播树被完全废弃。因此,这种方案不适合用于对实时性要求较高的业务应用。
2.3 PMIPv6扩展移动组播方案
PMIPv6扩展方案中,MAG和LMA都是运行PIM-SM(Protocol Independent Multicast-Sparse Mode)协议的组播路由器,如图4所示。本方案中,MRIB的建立依赖于单播路由表,所以PIM-SM协议根据RPF算法可以从MAG的MRIB中选择出一条最佳路由,这条路由可以是LMA-MAG隧道,也可以是网络中到其他相邻组播路由器路由。PIM信令报文通过选出的惟一的LMA-MAG隧道或普通路由发往被选中作为上游路由器的LMA或相邻的组播路由器,隧道汇聚问题就不会出现。
PMIPv6扩展方案不仅可以打破MAG只能配置为MLD代理的局限性,还可以利用PIM-SM协议动态选择最优路由。但是LMA-MAG隧道可能并不能被选为最佳路由。RPF算法计算MRIB中每条目的地址为组播源的路由,选出其中开销最小的发送PIM加入消息建立组播树。在单播路由表中,PMIPv6隧道路由和一般的单播路由条目不同,它作为一个基于源的策略路由,默认路由指向PMIPv6隧道。所以,如果把PIM-SM部署在MRIB没有被特别修改的MAG上,PIM-SM协议在常规的单播路由表中只能选择基于目的的路由发送加入/剪枝消息,而不会选择PMIPv6隧道。即使在PIM-SM的MRIB中建立一个目的地址为组播源,下一跳为PMIPv6隧道的默认路由也很难实现,因为PMIPv6单播路由的建立依赖于MN。而MN何时接入,是否接入几乎都是不可控的。另一个难以解决的问题是,即使PIM-SM的加入/剪枝消息不使用RPF算法进入了LMA-MAG隧道,当组播数据到达MAG进行RPF检查时也会因为到达接口不一致丢弃组播数据。
3 多上游接口MLD代理移动组播
3.1 设计思路
MLDv1[7]协议中存在“响应抑制”机制,如果一台主机在发送报告报文之前收到其他主机的报告报文,读取该报文的组地址,如果和自己要加入的组地址一致,则不再发送报告报文,可以避免多台主机发送相同的报告报文。这种机制要求所有主机都在同一个网段上,但是多实体MLD代理的多个下游接口可能并不在同一网段上,所以主机间接收不到报告报文。此外这种抑制机制不能记录成员信息,不能在桥式的LANs中工作而且主机对消息处理的工作量较大,在MLDv2协议中已经被废除。
MLDv2[8]取消了“响应抑制”机制之后,路由器不仅可以知道子网上是否有组成员,还具有记录每个组成员信息的能力,这种能力可以由路由器的“显式组播成员追踪功能”[9]实现。本文提出基于“显式追踪”功能的多上游接口MLD代理实体,上游接口对应不同的LMA,MAG借助“显式追踪”功能记录下游接口的所有组成员信息。如果已经有组成员发送了报告报文到MLD代理的上游接口,则加入相同组的其他成员不再发送报告报文。
3.2 “显式追踪”功能
有“显式追踪”功能的MLD代理在缓存中为每个组播组维护一个组成员状态列表,记录接入所有下游接口的所有组播接收者的状态,如图5所示。其中,S代表源的地址,如果是任意源的情况,则置为NULL;G代表请求加入的组播组地址;接收者个数和接收者记录分别是请求加入此组播组的成员个数和成员地址。
为了列表中的成员状态和实际成员状态能够同步,只要MLD代理接收到现状报告报文或者状态变化报告报文,就在接收者记录中动态地增加或删除接收者的IP地址或者创建新的组成员状态信息。如果这个组中没有接收者记录存在了,则从MLD代理缓存中删除这个组的成员状态信息。此外,根据组成员状态信息,只有第一个加入组和最后一个离开组的成员才发送状态变化报告到MLD代理相应的上游接口并发送特定询问消息到下游接口。当大量MN接入时MLD代理需要记录的状态信息量很庞大,所以要求有“显式追踪”功能的路由器有足够的存储资源。
3.3 多上游接口MLD代理移动组播工作机制
与多MLD代理实体上游接口的部署情况相似,多上游接口MLD代理的每个上游接口对应一个LMA。属于相同LMA的MN接入MLD代理的下游接口时,选择相同的MAG-LMA隧道接口作为上游接口,并使用“显式追踪”功能,记录下游接口的所有组成员状态。
MLD代理的上游接口收到一般查询消息之后,转发到所有接入到下游接口的MN。本方案采用和RFC6224相同的询问机制,一旦有MN接入下游链路,MLD代理就会发送一般询问消息,不必等待询问周期到来时再发送,此机制有效地减少了加入延时。MN接收到查询报文后,就为每一个要接收的组地址启动一个延时定时器。定时器的值在[0,最大响应时间]之间取一个随机数。定时器到期后,MN会发送报告报文到MAG通告MN想接收的组播组地址。MLD代理的下游接口接收到MN发送的报告报文之后,记录下每个组播组的成员状态信息。在“接收者记录”一项中,最先被记录的成员发送报告报文到MLD代理的上游接口,此上游接口就是这个成员所属的LMA-MAG隧道接口。其他后被记录的成员如果检测到已经有组成员发送了报告报文,则不再发送相同的报告报文到其所属的LMA-MAG隧道。一旦最先被记录的组成员离开组,按顺序选择其次被记录的成员发送报告报文。
与RFC6224中的拓扑相似,MN1和MN2分别隶属于LMA1和LMA2,通过MLD代理的两个下游接口接入MAG,建立Tun1,Tun2两条隧道,分别作为MLD代理的两个上游接口。MN1和MN2加入相同的组播组,地址为ff1e::111。LMA1和LMA2分别通过两条隧道向MAG发出一般查询消息。MN1和MN2在自己的计时器到期之前发出报告报文。MLD代理的下游接口接收到两份报文后记录组成员状态信息,组成员状态信息如图6所示。如果MN1最先发送了报告报文,则MLD代理将此报文向Tun1上游接口转发,之后MN2发送的报告报文不再向Tun2转发。如果MN1离开此组或者切换到别的MAG,MLD代理则转发MN2的报告报文到对应的上游接口。基于这种机制,隧道汇聚问题从根本上得到了解决。
3.4 性能分析
多上游接口MLD代理移动组播在RFC6224的部署基础上解决了隧道汇聚问题,避免了MTMA移动组播、直接路由移动组播和PMIPv6扩展移动组播方案的设计缺陷。主要包括:
(1) 选择简单轻便的MLD协议代替庞大复杂的PIM-SM协议,省去了PIM-SM协议在PMIPv6域中部署的复杂性,不消耗PMIPv6隧道以外的隧道封装开销;
(2) 若MN发生切换,LMA以外的组播树不必重新建立,可以降低切换延时,而且即时的询问机制也大大降低了移动组播成员加入组的延时;
(3) 多上游接口MLD代理移动组播的“显式追踪”功能可以减少状态变化报告报文发送的数量,降低网络拥塞的概率。
4 各种移动组播方案性能比较
通过上述分析,可以比较出四种方案的特点,如表3所示。本文方案与MULTIMOB中的其他三种方案相比,协议简单,拓扑简单,封装开销和加入延时较小,容易部署。此外低报文发送量的特性使其适应于拥塞严重的网络环境,但记录成员状态功能对路由器的存储量却有较高要求。
5 结 语
本文针对“隧道汇聚”问题,提出一种基于多上游接口MLD代理移动组播的解决方案。本方案通过在MAG上部署多上游接口的MLD代理,代替RFC6224中多实体的MLD代理,并利用“显式追踪”功能记录其下游接口所有组成员状态。本方案不仅可以解决“隧道汇聚”问题,而且更加简单轻便,无需额外的隧道封装开销,有较小的组播组加入延时,比MULTIMOB工作组中其他三种方案更具优势。此外,多上游接口MLD代理具有很强的可扩展性,也可以在源移动的场景下解决多实体MLD代理带来的问题。
参考文献
[1]GUNDAVELLI S.RFC5213proxy mobile IPv6[S].Fre-mont:IETF,2008.
[2] JOHNSON D, PERKINS C, ARKKO J. RFC3775 mobility support in IPv6 [S]. Fremont: IETF, 2004.
[3]SCHMIDT T,WAEHLISCH M,KRISHNAN S.RFC6224base deployment for multicast listener support in proxy mo-bile IPv6(PMIPv6)domains[S].Fremont:IETF,2011.
[4] ZUNIGA J C, CONTRERAS L M, BERNARDOS C J, et al. Multicast mobility routing optimizations for proxy mobile IPv6 (IETF draft) [S]. Fremont: IETF, 2012.
[5] ASAEDA H, SEITE P. Multicast routing optimization by PIM-SM with PMIPv6 (IETF draft) [S]. Fremont: IETF, 2012.
[6]FENNER B,HE H,HABERMAN B.RFC4605Internet group management protocol(IGMP)/multicast listener dis-covery(MLD)-based multicast forwarding(IGMP/MLD Proxying)[S].Fremont:IETF,2006.
[7]DEERING S,FENNER W,HABERMAN B.RFC2710 multicast listener discovery(MLD)for IPv6[S].Fre-mont:IETF,1999.
[8] VIDA R, COSTA L. RFC3810 multicast listener discovery (MLDv2) for IPv6 (Version 2) [S]. Fremont: IETF, 2004.