第9章分布式传感与控制的信息发布.docx
- 文档编号:16824384
- 上传时间:2023-07-17
- 格式:DOCX
- 页数:22
- 大小:116.04KB
第9章分布式传感与控制的信息发布.docx
《第9章分布式传感与控制的信息发布.docx》由会员分享,可在线阅读,更多相关《第9章分布式传感与控制的信息发布.docx(22页珍藏版)》请在冰点文库上搜索。
第9章分布式传感与控制的信息发布
第9章分布式传感与控制系统的消息订阅/发布/通知模型
9.1引言
在由传感器网络、机器人和多种通信装置组成的分布式传感与控制系统中,一个或者多个传感器网络(或其中的部分传感器节点)作为系统的传感节点和数据源,而机器人作为系统的控制节点。
机器人可能是静止或者可以移动的。
系统中的多种通信装置则保证传感器网络和机器人的有效连接。
在这个系统中,来自多传感节点的数据可形成源源不断的连续数据流,使用有线或者无线网络,通过通信装置传递给一个或多个控制节点。
这种情况下控制节点必须连续地接收和处理数据流中的数据,执行相应的动作。
但是来自传感节点的数据流中很大部分的数据对某些控制节点而言是没有意义的甚至是可以忽略的。
连续的数据流给网络传输系统带来了沉重的负担,严重时会导致数据传输的延时和超载,影响分布式传感与控制系统重要命令的执行和数据的传输。
另一方面,在这种数据传输模型下,系统中的控制节点和传感节点必须在同步方式、通信方式和数据结构等方面紧密耦合。
控制节点必须清楚了解传感节点的物理连接方式及传感节点发送数据的格式,在接收到传感节点发送的数据时必须及时进行解析和处理。
传感节点和控制节点的紧密耦合是整个系统的开发、维护和复用的障碍。
在本章,将讨论在分布式传感和控制系统中,引入了分布式的消息订阅/发布/通知模型,解除控制节点和传感节点之间存在的多种紧密耦合,降低网络中的数据传输负担、提高网络的数据传输性能,减轻控制节点的数据处理量,为分布式传感和控制系统的开发和部署提供一种新的解决方案[1~5]。
在分布式消息订阅/发布/通知模型下,各个控制节点作为传感节点感知数据的使用者,可以按照一定的模式,指定自己感兴趣数据的特征和应符合的条件,并在系统中发布,订阅自己需要的数据和信息。
各种传感节点作为系统中的数据源,向系统发送自己感知的数据,数据在系统中的发送构成了事件,触发系统中一系列的动作。
如果事件中的数据满足某个控制节点的数据订阅条件时,则将数据封装成一条通知消息,在系统中使用异步数据传输方法,传递给相应的控制节点。
控制节点根据自己的需要,对通知消息中的数据进行处理,并执行相应的动作,完成自己的功能。
通过在分布式传感和控制系统中引入消息订阅/发布/通知模型,控制节点和传感节点在通信和同步方式及数据结构方面的紧密耦合将被打破,控制节点可以不用知道传感节点的连接方式和数据格式等细节信息,只需要接收和响应符合自己订阅条件的通知消息。
这样可以简化系统的构建方式,提高系统的可维护性和可重用性。
9.2分布式系统的消息订阅/发布/通知模型
消息订阅/发布/通知是一种适合于松散耦合和事件驱动的分布式系统信息交互模型,它可以有效解除系统中各组件之间的紧密耦合。
在这个模型中,一般包含下面几类实体:
(1)信息发布者和订阅者,是需要依据消息进行交互的组件,也是数据的产生者和消费者;
(2)事件:
数据源产生的数据将导致系统中一个或一系列事件的发生。
事件可以看成是一种可观察的现象的发生;
(3)订阅:
数据消费者向系统注册自己需要的数据的特征及应满足的条件;
(4)通知:
数据发布者和数据订阅者之间信息交流的方式。
符合订阅条件的数据被系统封装成通知,传递给数据订阅者。
(5)代理:
连接数据产生者和数据消费者的节点。
发布者发布的数据通过代理传递给数据消费者。
数据发布者和消息订阅者通过网络系统进行交互,两者之间的关系如图9.1所示:
图9.1分布式消息订阅/发布/通知模型
基于事件进行交互的系统中的客户可以是数据的产生者或消费者。
当传感节点感知的数据发送到系统时,系统首先将该数据和控制节点预先提交的数据订阅条件进行测试,如果满足控制节点提交的数据订阅条件,则系统创建一个通知消息,对数据进行变换,并附着在通知消息中,通过系统中的代理节点进行转发,将该通知消息传递给控制节点。
这样,传感节点和控制节点之间没有直接和固定的连接关系,双方可以独立开发、升级和维护,甚至彼此都可以不用预先知道对方的存在。
订阅描述了控制节点感兴趣的数据必须符合的条件,它可以看成是一个boolean表达式[6],系统使用该表达式来测试传感节点产生的数据。
如果测试结果为真,则形成通知并传递给数据消费者。
否则,系统可以对该数据不进行任何处理。
在分布式传感和控制系统中,引入消息的订阅/发布/通知模型,可以达到如下几个目标:
(1)打破控制节点和传感节点之间的紧密耦合,使两者可以在不依赖对方的情况下独立开发、部署、演化、维护和重用。
(2)控制节点的消息驱动处理机制:
控制节点只需要接受通知,处理通知中的数据,根据自己的需要执行特定的操作。
不需要知道通知中包含数据的产生和传递过程,甚至可以不需要知道消息的来源。
(3)消息在传递过程中,可能经过过滤、缓冲和压缩等操作,控制节点可以不考虑这些操作。
(4)减少网络中数据的传输量,减轻网络的数据传输负担,简化系统中的网络连接。
(5)减轻控制节点的负担,使控制节点从连续侦听、接收和处理来自多个传感节点源源不断数据中解脱出来,只需要处理接收到的符合节点自身需求的数据。
B:
代理节点
在分布式传感与控制系统中,消息订阅/发布/通知模型的基本结构如图9.2所示,其核心是由多个代理节点组成的网络系统,代理节点可以是传感节点、控制节点或其它可以进行数据存储和转发的装置。
代理节点之间可能通过一定的网络通信协议连接(有线、无线等方式),完成信息的接收、存储和转发等工作。
图9.2、代理网络的基本结构
系统中的节点可以分为内部代理节点和边缘代理节点。
边缘代理节点为控制节点,是数据的消费者,内部代理节点负责完成信息在节点间的转发。
根据系统中节点的不同特点,可以把分布式传感与控制网络系统分为三类。
(1)固定结构:
所有节点的位置及节点间的连接关系都是固定的,不会随时间发生变化。
(2)Nomadic结构:
边缘代理节点可以移动,与不同的内部代理节点进行连接,从不同的内部代理节点处接收通知[7]。
(3)移动Ad-hoc类型:
所有的代理节点都可以移动,系统中无固定的节点连接关系。
可能需要动态建立从源节点到目标节点的消息传递路径。
下面几节中,针对这几种类型的分布式传感与控制系统,将分别讨论分布式消息订阅/发布/通知模型的实现机制。
9.3固定结构系统的消息订阅/发布/通知模型
在这种体系结构的分布式传感与控制系统中,由于各种代理节点之间的连接关系固定,所以消息的订阅/发布/通知机制比较容易实现,可以使用固定的消息传递途径完成订阅和通知消息的传递。
9.3.1模型的实现
在系统中,可以指定一个代理节点存储整个系统的全局注册机构,保存系统中所有的传感节点及其向系统发送数据的概要信息、所有控制节点的指定的订阅条件等信息。
同时,在全局注册机构中,还保存整个系统中所有节点的信息及节点间的静态连接关系。
系统的所有节点中,都设置一个路由表,保存经过该节点的所有消息传递路径的相关信息。
同时,在所有传感节点中,都保存一个局部的注册表,保存订阅该传感节点数据的控制节点标识及其指定的订阅条件。
在传感节点产生数据时,将数据和存储的控制节点指定的消息订阅条件进行对比。
如果数据能匹配某个控制节点指定的消息订阅条件,则创建一个通知消息,将数据附着在通知消息中,并查询节点中的路由表,将通知消息沿指定的路径传递给控制节点。
在控制节点C提出消息订阅条件F时,该节点首先在系统的全局注册机构中注册节点标示和订阅条件F,然后在全局注册机构中检索符合指定的订阅条件的传感节点,根据全局注册机构中保存的代理节点之间的静态连接关系,找到从控制节点到该传感节点的最短路径。
之后,控制节点形成一个订阅(subscribe)消息,并把最短路径中的节点序列附着在该消息中,沿节点间的最短路径,传递该订阅消息。
消息传递路径中的每个节点,在接收到订阅消息时,都首先更新自己的路由表,加入发布该订阅消息的控制节点标识和订阅条件F、以及消息传递路径中的前一个节点和后一个节点的标识,同时判断节点自身是否为订阅消息的目标节点,如果不是,则找到消息传递路径中的下一个代理节点,并将订阅消息传递给该节点。
如果节点自身是订阅消息的目标节点,还需要将控制节点标识和订阅条件保存在自己的局部注册表中。
在传感节点产生数据时,首先检查节点自身的局部注册表,查看是否有能被该数据满足的订阅条件。
如果控制节点C和订阅条件F能得到满足,则针对节点C和订阅条件F,创建一个通知消息(notification),将数据附在消息中。
在路由表中查找相应的通知传递路径中的下一个节点,将通知消息传递给该节点。
系统中的节点在接收到通知消息时,在自己的路由表中查找对应于控制节点C和订阅条件F的消息传递路径中的下一个节点,并将该通知消息转发给该节点。
最后,通知消息被传递到控制节点C中,节点C根据自己的需要对通知消息中的数据进行处理。
如果控制节点要取消某个订阅条件,则首先在系统的全局注册机制中取消对应的注册项,然后创建一个取消订阅消息(unsubscribe),并沿和订阅消息相同的路径进行传递。
每个节点在接收到该消息时,首先删除节点的路由表中相应的数据项,然后将取消订阅消息转发给下一个节点。
最后当传感节点接收到该取消订阅消息时,除了删除路由表中的数据项外,还需要删除自己的局部注册机构中保存的相应数据。
在分布式传感与控制系统中,以下算法描述了节点处理订阅消息的算法。
voidOnSubscrbe(Subscribe(C,F,Source,Dest,[B1,…,Bn])){
//找到当前节点的在[B1,…,Bn]中的位置
for(inti=1,i<=n,i++){
if(Bcurrent==Bi)break;
}
routeTable.Update(C,F,Bi-1,Bi+1);//更新路由表
if(i {deliverToNext(Bi+1,Subscribe(C,F,S,D,[B1,…,Bn])//传递给下一个节点 } else{ localRegistry.Add(C,F);//局部注册机构加入客户C和F } } 以下算法描述了节点处理通知消息的方法。 voidOnNotify(notify(C,F,Source,Dest,content)){ if(Bcurrent==Dest){//当前节点是否目标节点 delivetToApp(C,F,content);//传递给应用程序 }else{ nextNode=routeTable.Lookup(C,F);//在路由表中检索下一个节点 deliverToNext(nextNode,Notify(C,F,Source,Dest,content));//传送给下一个节点 } } 以下算法描述了节点在接收到取消订阅消息时,其处理方法。 voidOnUnsubscribe(unsubscribe(C,F,[B1,…,Bn])){ //找到当前节点的在[B1,…,Bn]中的位置 for(inti=1,i<=n,i++){ if(Bcurrent==Bi)break; } routeTable.Remove(C,F);//更新路由表,删除C,F项 if(i deliverToNext(Bi+1,unsubscribe(C,F,S,D,[B1,…,Bn])//传递给下一个节点 }else{ localRegistry.remove(C,F);//局部注册机构删除客户C和F } } 通过这样的机制,可以实现固定连接结果的分布式传感和控制系统中的消息订阅/发布/通知模型。 9.3.2在Player/Stage中的应用实例 结合以上实现方法和算法,我们提出并实现了一个基于Player/Stage的分布式消息订阅/发布/通知模型的多机器人控制框架。 如本书前面章节所述,在机器人控制框架Player中,Player可以配置大量的传感器,客户端通过TCP协议和Player连接,读取传感器的数据,监视机器人的运行,并向机器人发送指令。 Stage则以Player为基础,模拟了由多个机器人、传感器和其它物体组成的一个环境,提供了一个实时多机器人控制的仿真实验手段。 在这样的传感和控制结构中,客户应用必须和Player紧紧耦合在一起,不单要建立直接的通信链路,而且必须知道Player所配置的传感器数目、类型和产生数据的格式,并连续监听来自player的数据,对数据进行及时的处理。 同样,大量从Player发往客户端的数据都是没有太大的意义的,客户端通常可以自己计算Player的状态。 持续的数据发送会导致网络中数据传输负担的加重,严重时会造成网络通讯的延迟。 在典型的Stage应用中,通常在系统中有多个分布的客户端和多个运行在不同环境中的Player,这样,整个网络中的网络连接数目更多,数据传输负载更重,可能会超出网络的负载能力。 为此,提出了基于分布式的订阅/发布/通知框架,重新构建Player应用系统的结构。 在这种系统结构中,应用系统和Player并不直接连接,而是通过一个服务器连接在一起。 应用系统向服务器指定自己需要数据的条件,来订阅自己需要的Player相关数据,Player向服务器发布自己产生的数据,当数据符合应用系统订阅的条件时,服务器根据Player的数据,形成一个通知,发送给应用系统。 通过这样的结构,可以解除客户应用和Player之间的直接耦合,使应用系统不再直接依赖于具体的Player,可以相对独立地开发和演化;另一方面,这种结构模式大大减少了网络系统中通信连接的数目。 而且,由于只有在Player产生的数据符合应用指定的条件时才进行传送,网络系统中的数据的流量也大大减少。 整个系统的结构如图9.3所示[8]。 P la y e r s 图9.3采用订阅/发布/通知模型的Player应用体系结构 9.4Nomadic系统中的消息订阅/发布/通知模型 Nomadic系统,是指系统中的内部代理节点的位置和连接关系固定不变,但是边缘代理节点可能会消失或移动。 在边缘代理节点移动时,可以和原来连接的内部代理节点失去连接,并和新的代理节点建立连接关系。 边缘代理节点在移动时和不同的内部代理节点失去并重新建立连接的过程,称之为漫游或游牧。 9.4.1模型的需求及实现 Nomadic系统中的分布式消息订阅/发布/通知模型,应满足下面几个方面的需求。 (1)边缘代理节点移动的透明性: 为了保持和固定结构系统中消息订阅/发布/通知模型的兼容性,Nomadic系统中应为移动节点提供透明的消息订阅/发布/通知机制的支持,使其不需考虑漫游时连接的内部代理节点的转换。 (2)消息传递的完整性: 除非控制节点无法连接,否则不管该节点是否处于漫游状态,系统应保证能把发送该节点的全部通知消息完整地传递给该节点。 (3)消息传递的良序性: 在分布式传感与控制系统中,控制节点可能对接收到的通知消息的时间顺序有严格的要求,来自于同一传感节点的消息要按照正确的时间顺序传递给控制节点,而不管节点是否处于漫游状态。 (4)消息传递的及时性: 由于节点漫游而导致的系统中通知消息传递路径的重构,应尽可能使用少的时间和花费尽可能少的代价,使该节点尽早接收到通知消息。 为了在Nomadic系统中的实现满足以上要求的分布式消息订阅/发布/通知模型,系统中的代理节点必须具备如下的两项功能: (1)具有缓冲功能,能把暂时无法传递的消息暂时缓冲起来。 (2)内部代理节点必须能在边缘节点进入自己的通信覆盖区域时主动发现这些节点。 这可以通过代理节点发送心跳(Heartbeat)消息完成。 基于这两个前提,我们提出了支持控制节点漫游的分布式通知传递模型。 在控制节点漫游并和不同的内部代理节点重新建立连接时,其通知传递路径的重构可以通过下面的三个步骤完成。 (1)节点漫游消息的传播: 在移动的控制节点移动并和新的代理节点连接后,系统必须为该控制节点建立新的通知传递路径。 根据网络的连接结构,新的通知传递路径可能和原有的通知传递路径在某个节点处相交。 我们把此节点称为交汇代理节点。 找到第一个交汇代理节点后,节点漫游消息的传播步骤结束。 (2)fetch消息的发送: 找到交汇代理节点后,从该交汇节点沿原通知传递路径发送一个fetch消息,用于查看原通知传递路径中那些部分是可以抛弃的,哪些部分是需要重新定向到新的通知传递路径上的。 这一点在漫游节点接收来自多个数据源的通知时尤为重要。 在fetch消息传送到原来控制节点直接连接的代理节点后,这个步骤结束。 (3)通知传递路径的重分配: 这个步骤负责将在原来连接节点中缓冲的通知消息重新发送给漫游后的节点。 当原来的连接节点接收到fetch消息时,将自己缓冲的发送给该漫游节点的通知,按照时间顺序结合在一起,创建一个新的replay消息,沿fetch消息传递的反方向发送给交汇代理节点。 同时,在旧的通知传递路径中进行垃圾回收工作,把不再继续使用的部分路径拆除,修改这部分路径中代理节点的路由表。 然后从交汇代理节点处,把replay消息按照为漫游节点新建立的通知传递路径进行传递。 通过这三个步骤,不但将缓冲的通知按照正确的时间顺序发送到漫游节点,而且,建立了新的通知传递路径。 这三个步骤的工作过程如图9.4所示: 图9.4单数据的控制节点漫游过程 为了使Nomadic类型的分布式传感与控制系统中的订阅/发布/通知模型和固定结构系统的模型兼容,需要对该模型作如下的修改: (1)当漫游的控制节点接收到来自于新的内部代理节点的心跳消息时,自动重新发布自己的消息订阅条件。 (2)引入一些新的消息类型,以实现向漫游节点通知传递路径的重新分配,并更新系统中部分节点的路由表。 (3)把缓冲的消息,按照正确的时间顺序重新发送给漫游后的节点。 在这个过程没有完成前,需要暂时缓冲沿新建立的路径传送给该节点的消息。 (4)由于漫游节点接收的通知可能来源于一个或者多个数据源,其处理方式有少许的区别。 下面我们针对这两种情况分别进行讨论。 9.4.2单数据源的控制节点漫游 如图9.4所示,当控制节点C从代理节点B6漫游到和代理节点B1连接时,根据前面的讨论,首先,节点C接收到来自于B1的心跳消息后,根据以前的消息订阅请求自动重新创建一个消息订阅请求,并从B1节点发送。 第二步,要在系统为控制节点C重新构建通知传递路径,更新相关节点的路由表,并把缓冲起来的通知消息按照时间顺序重新发送给控制节点C。 为此,从C中重新发送的订阅消息,在系统中向相应的传感节点沿最短路径传递。 在本例中,从B2,经过B3,到达B4。 B2和B3节点在传递订阅消息时,更新自己的路由表,保存关于节点C和订阅条件F的相关信息。 新的通知传递路径和原有的通知传递路径在代理节点B4处相交,节点B4根据自己的路由表可以判断自己为交汇代理节点。 在B4节点中,更新节点C和订阅条件F的数据项,即可把发送给节点C的通知按照新的传递路径传递。 这样,只须更新系统中少量节点的路由表,就可以完成漫游节点的通知传递路径重构。 但是此时,B1节点还不能把接收的通知直接传递给节点C,需要临时进行缓冲。 第三步,为了保证节点C接收到通知的完整性,需要把由于节点C无法连接而缓冲在B6的通知重新发送给节点C。 为此,交汇代理节点B4沿原来的通知传递路径发送一个fetch消息到B6。 接收到fetch消息的代理节点更新自己路由表中的相应数据项,将该数据项中的下一个节点和上一个节点交换。 代理节点B6作为fetch消息的最后接收者,将缓冲起来的发送给节点C的通知按照接收的时间顺序结合在一起,形成一个replay消息,根据修改后的路由表,传递给节点B4。 B4节点接收到replay消息后,按照为客户C重新建立的通知传递路径,发送给节点B1。 在B6发送replay消息后,将其路由表中关于客户C的数据项删除,在从B6到B4的replay消息传递路径中的所有代理节点,都在发送完replay消息后,在自己的路由项中删除有关客户C的项。 最后,代理节点B1在接收到replay消息后,把replay消息的内容传递给控制节点C,并将自己缓冲的发送给节点C的通知,按照接收的时间顺序发送给客户C。 此后,整个分布式传感与控制系统开始正常的通知发送、传递和接收工作。 9.4.3多数据源的控制节点漫游 对上面描述的过程进行扩充,就可以订阅了多个传感节点数据时的控制节点漫游过程。 如图9.5所示,除了控制节点C接收了来自多个数据源的通知外,和图9.4的其它情况是相同的。 图9.5多数据元的控制节点漫游过程 为了处理来自多数据源的通知,从B4到B6路径中的每个节点都需要检查自己的路由表中是否有多个对应于控制节点C的数据项。 如果有,则该节点和B4节点一样,也是交汇代理节点,从该节点到B4的通知传递路径不能抛弃。 为了找到原通知传递路径中的最后一个交汇代理节点,需要对前面提出的fetch消息和replay消息的传递机制进行修改。 在从B4通向B6的传递路径中传递fetch消息时,路径中的某个节点如果发现自己的路由表中有多个对应于移动节点C的项,则使用该节点的标识替换fetch消息中消息源节点的ID。 在图9.5中,B4首先使用自己的ID设置fetch消息的ID,然后B5节点发现自己的路由表有两个数据项对应于控制节点C,则使用自己的ID替换fetch消息的源节点B4。 这样,B6节点接收到的fetch消息的源节点ID是B5。 通过replay消息,可以删除原来路径中不再需要的代理节点。 在replay消息中,放置fetch消息的源代理节点的ID。 当某个节点接收到replay消息时,根据消息中存放的fetch消息的源代理节点ID的不同情况,可能会执行如下不同的操作。 (1)该ID和节点自己的标识不同,表示节点不在新的通知传递路径上,转发replay消息,清理自己的路由表. (2)该ID和节点的标识相同,表示该节点是最后一个交汇代理节点,删除自己路由表中对应于控制节点C和订阅条件F的数据项,并把replay消息中fetch消息的源节点ID置为空,并转发replay消息; (3)ID为空,表示该节点是新的通知传递路径中的节点,直接转发replay消息。 比较图9.4和图9.5,可以看到,在单数据源时,B5和B6节点中对应控制节点C的路由项全部收回。 但在多数据源时,节点B5中对应控制节点C的数据项不能全部收回,部分数据项需要更新。 通过这样的机制,保证了控制节点在Nomadic系统中漫游,与不同的内部节点动态取消和建立连接时,分布式订阅/发布/通知模型仍然能继续正常工作。 以下算法描述了内部代理节点和漫游的控制节点连接,接收到其发布的订阅消息和replay消息时的算法。 voidreceiveSub(C,F,num,Lc){ if(! RoutingTable.Contains(C,F){//C和F未包含在路由表中,新订阅 routeTable.add(F,C,Lc);//路由表中加入新项 initializeCache(C,F);//初始化对客户C的缓冲 if(num>0){ //锁定,一直等到路径重分配结束 RoutingTable.setBlockingFlags(C,F,Lc,true); } propagate(C,F,Lc);//把C和F递给下一个节点 } sendCache(C,F);//给C发送缓冲的消息 } //节点从Bj处接收到一个fetch消息时 voidreceiveFetch(C,F,num,Bprod,Bj
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 分布式 传感 控制 信息 发布
![提示](https://static.bingdoc.com/images/bang_tan.gif)