面向物联网的闭环全生命周期管理系统中间件设计
2017-04-24许宜春
程 健 许宜春 桑 成
(中国科学技术大学信息科学技术学院 安徽 合肥 230027)
面向物联网的闭环全生命周期管理系统中间件设计
程 健 许宜春 桑 成
(中国科学技术大学信息科学技术学院 安徽 合肥 230027)
为了在闭环全生命周期管理系统中提供高效的数据服务,解决众多异构系统信息交互和全生命周期内信息分享等方面的问题,建立了一种基于物联网协议MQTT和NIO框架Netty的中间件。首先,简要概述了闭环生命周期管理的内涵和系统架构;其次,在分析闭环生命周期管理系统中间件特点的基础上,设计了中间件的软件架构和处理过程;最后,设计了测试实验并进行了测试。测试结果表明,闭环全生命周期管理系统中间件能够快速有效地实现无效产品数据过滤,在大数据量和数据服务订阅者模式下,中间件的普通消息处理平均时间维持在8.56 s以内,系统平均吞吐率为2 162 packets/s,可以满足闭环全生命周期管理数据服务的应用需求。同时,该中间件也非常适合于拥有大量传感器节点的物联网环境,实现大数据量系统的数据采集和分发基础服务。
闭环全生命周期管理 Message Queue Telemetry Transport(MQTT) Netty 中间件 物联网
0 引 言
目前,企业产品数据管理工具主要有:计算机辅助设计/制造(CAD/CAM)、产品数据管理(PDM)、产品生命周期管理(PLM)等。这些工具主要实现产品设计生产阶段数据的管理,无法形成产品全生命周期信息流闭环管理。闭环全生命周期管理CL2M(Closed-Loop Lifecycle Management)[1]为解决上述问题提供了新思路,它主张在产品中嵌入信息装置PEID(Product Embedded Information Device),跟踪和收集产品数据,建立产品数据&知识管理PDKM(Product Data & Knowledge Management)系统,存储、分享产品数据、信息和知识,从而达到高效管理产品全生命周期活动的目的[2]。
CL2M系统的体系结构如图1[3]所示。数据获取层实现产品全生命周期数据获取,数据管理层提供基础中间件、数据存储、决策DSS(Decision Support System)与数据挖掘等核心功能。PLM商业应用层依托数据管理层提供个性化产品服务与物联网服务,如租赁型产品服务、产品故障诊断与预测维护服务等。
图1 CL2M系统体系结构[3]
CL2M系统中间件又称CL2M数据服务,旨在为CL2M系统构建基础产品数据服务网络,并通过通用信息交换标准接口为系统其他组件(如PEIDs、PDKM、DSS)和第三方组织等异构系统(如仓储管理系统、移动应用等)提供产品全生命周期数据获取、持久化与分享等服务。CL2M系统中间件具有以下特点:
1) 提供通用信息交换标准接口,实现CL2M系统不同组件和后端系统集成,并与其他异构系统信息交互。
2) 安全和隐私。不同用户对产品数据拥有不同权限,必须保证用户在权限允许范围内获取正确的产品数据。
3) 持久化服务[4]。请求数据不可达或用户不可达时持久化请求或响应数据。
4) 支持订阅服务[4]。通过订阅关注产品,用户便能获得不断更新的产品全生命周期数据。
5) 支持无效数据过滤。中间件涉及不同产品数据源交互,数据繁多,为提高处理效率,须对无效数据过滤,防止无效数据充斥数据服务网络。
6) 并发性、实时性。传统企业应用环境下,与中间件交互的节点有限,并发性要求不高。但CL2M系统扩展至物联网中所有节点生命周期管理时,并发性则是一项重要性能指标。中间件没有强实时要求,但必须保证一定的消息处理实时性。
目前,针对CL2M系统及其中间件已有一定研究成果。J.Cassina、D.Kiritsis等研究了物联网环境下CL2M系统架构,提出PMI(PROMISE Message Interface)作为系统中间件通用信息交换接口[5-6]。Kary Framling等基于Dialog架构与CL2M系统架构的相似性,研究了在Dialog代理中构建CL2M中间件问题[7-8]。Sylvain Kubler等从产品生命周期管理角度出发,研究并提出了将产品管理扩展至物联网“万物”管理的中间件信息交换标准QLM(Quantum Lifecycle Management)[4,9]。国内,王旭等对CL2M理念进行了综述研究[10],刘刚研究了产品全生命周期数据的统一建模与各个阶段数据映射理论[11],对于CL2M系统中间件及其信息交换标准的研究尚属空白。
但,文献[7-8]基于Dialog设计的系统中间件更适合产品物流管理,文献[4-6,9]提出的中间件信息交换标准依赖HTTP等协议,并不适合于物联网环境中资源受限的设备。本文在轻量级物联网协议MQTT(Message Queue Telemetry Transport,消息队列遥测传输)基础上,提出满足CL2M系统信息交互环境的CL2M系统中间件设计,并扩展至物联网环境下大量传感器节点管理的基础数据中间件服务应用。
1 CL2M系统中间件架构设计
CL2M系统中间件典型实现模式为点对点P2P,而发布/订阅(Publication/Subscribe,Pub/Sub)作为一种新的消息中间件实现模式,具有异步、松耦合互联、多对多通信、体系结构开放和资源重组灵活等特点[12]。MQTT是一种基于发布/订阅模式设计的物联网消息传输协议,协议开放、简单、易用,非常适合网络、处理器、存储等资源受限的环境[13],因而适合作为CL2M系统中间件通用信息交换接口。而非阻塞异步框架Netty则是一种优秀的、用于高性能服务器开发的编程框架。
因此,本文基于MQTT和Netty设计CL2M系统中间件,包括发布/订阅核心执行引擎(包括消息收发、消息缓存池、消息过滤、订阅管理)、身份验证管理、ACL管理、自动订阅管理和心跳机制模块,同时为了便于用户通过浏览器主动请求获取产品生命周期数据,提供了Web服务。整个中间件的软件架构如图2所示。
图2 CL2M系统中间件软件架构
2 CL2M系统中间件模块设计
2.1 身份验证和ACL管理模块
产品的全生命周期阶段涉及设计人员、制造商、物流公司、产品用户、维护/维修专家及回收操作员等用户。为规范用户操作行为,确保数据的安全和隐私,基于用户名和用户密码设计身份验证表,基于产品消息主题和用户ID设计主题访问权限控制表ACL(Access Control List)。
用户第一次发起连接请求时,身份验证模块利用连接包中的用户名和密码实现身份验证。
用户订阅或发布主题消息时,ACL管理模块用于验证用户是否具有对该主题订阅或发布的权限,若用户拥有权限则进行后续操作,否则拒绝订阅或发布操作。
2.2 自动订阅模块
实际应用中,用户手动订阅产品数据主题,但对于订阅大量产品主题消息的用户,重复性手动订阅不仅影响用户体验,同时也占用了大量的网络资源。
因此用户第一次发起连接请求后,一旦身份验证模块通过身份验证,自动订阅模块便根据用户ID和ACL表为用户自动订阅权限范围内的产品数据主题,自动订阅模块的处理流程如图3所示。
图3 自动订阅流程
2.3 订阅管理模块
订阅管理模块是CL2M系统中间件核心处理引擎,负责订阅请求及发布消息的集中处理。
订阅管理模块处理订阅消息的过程如图4所示。数据收发模块收到客户端C发出的主题T订阅请求“Subscribe(C,T)”后交由消息缓存池模块进行消息解析、分类,确定为订阅消息后由订阅管理模块利用ACL管理模块查询客户端对主题T的订阅权限,若客户端拥有对主题T的订阅权限则更新产品主题订阅表,并返回订阅成功确认信息;否则,则直接返回订阅失败确认信息。
图4 订阅产品消息处理过程
产品全生命消息的发布处理过程与订阅过程类似。当产品数据源发布的主题消息成功由消息过滤模块过滤后,订阅管理模块利用ACL模块实现发布权限管理,具有发布权限时则根据主题订阅表将该消息在数据库中持久化并转发给订阅该主题的用户,否则拒绝发布操作。
产品主题订阅表采用订阅树机制,即产品生命周期数据主题根据主题层级分隔符(‘/’)组织成树,从树的根节点至树中任意非根节点都构成一组产品生命周期数据数据主题,每一主题维护一组该主题的订阅者列表和主题消息队列。
2.4 消息缓存池模块
消息缓存池模块统一管理和缓存CL2M系统中间件收发消息,分为接收消息缓存池和发送消息缓存池。
2.4.1 接收消息缓存池
产品在生产、使用过程中,一些故障信息需要优先处理和分发,因此CL2M系统中间件处理的信息分为紧急信息、环境信息和一般产品使用消息。
为了达到紧急消息优先处理和分发的目的,接收消息缓存池基于区分优先级的多队列技术实现。接收缓存池的设计如图5所示。
图5 接收缓存池
总体紧急因子TEF(Total Emergency Factor)分类根据消息TEF值完成不同优先级消息入队。多优先级的多队列调度算法采用优先级加权轮询机制,即为不同优先级队列分配不同时间片处理权重。高优先级队列为空或时间片用完后轮询较低优先级队列,依次循环。这样既能防止优先级较高的队列持续占用处理资源,又避免了低优先级队列出现饥饿问题。队列内部采用先进先服务FCFS(Fisrt Come First Serve)策略。
2.4.2 发送消息缓存池
发送消息缓存池缓存反馈确认消息和CL2M系统中间件分发给不同订阅者的消息。缓存池维护5个消息缓存队列(包括outboundQoS2、outboundQoS1、 pendingMessages、pendingFlows、emergeningMessages),缓存池结构如图6所示。
图6 发送消息缓存池
区分outboundQoS2、outboundQoS1两个缓存的作用一方面用于提供不同服务质量的产品消息分发服务,另一方面用于在CL2M系统中间件异常崩溃状态下从文件系统中恢复消息发送现场。pendingMessages缓存从outboundQoS2、outboundQoS1取出的产品数据消息,pendingFlows主要缓存连接、订阅、发布等消息的确认消息。emergeningMessages缓存需要优先路由分发的消息。Send Handler对这3个缓存队列的处理优先顺序依次为emergeningMessages、pendingFlows和pendingMessages,并分配不同的处理时间片。
2.5 消息过滤模块
消息过滤模块实现非法或无效发布消息过滤。由于产品消息基于主题形式发布至中间件系统,而主题数目存在一定范围动态变化,因此,在允许一定假阳性误判概率情况下非常适合采用计数布隆滤波器CBF(Counting Bloom Filter)[14]实现快速消息过滤算法。
CBF继承了标准BF优秀的空间效率和查询时间,同时支持规则集动态变化时删除操作。CBF将标准BF的V向量的bit位扩展为计数器(Counter),通过对计数器的加减操作完成规则集的添加和删除。计数器扩展至4 bit即可满足大多数应用[15]。
基于CBF的消息过滤算法描述如下:(1) 主题规则集T={T1,T2,…,Tn}共有n个元素,通过哈希函数集H={h1,h2,…,hk}计算每一规则集元素的k个哈希值(值域为{0,1,…,m-1}),映射至长度为m的计数器数组,将对应k个计数器加1;(2) 对需要过滤的主题消息采用相同的哈希函数集计算k个哈希值,若对应k个计数器值都大于等于1则消息属于主题规则集,消息进行持久化并交由订阅管理模块分发。否则,判定不属于主题规则集,消息丢弃,不再进行后续处理。
消息过滤算法伪代码如下:
Algorithm: DataFilter (element)
Require: element is not null
1: CBF←GetCBF()
2: if CBF is null then
3: CBF←CreateCBF(p,T)
4: Hash1←GetHash1(element)
5: Hash2←GetHash2(element)
6: for i=0 to k-1 do
7: Addri←Hash1+i*Hash2 mod m
8: if CBF[Addri]= 0 then
9: Return false
10: Return true
2.6 心跳机制模块
CL2M系统中间件通过心跳机制模块确保与之交互的客户端连接,从而及时发现异常断开情况。若客户端在规定的可设置时间戳内没有与CL2M系统中间件交互的需求,需向中间件发送PING消息,告知连接正常,心跳机制模块返回PINGRESP消息。若CL2M系统中间件在规定时间超时后未收到PING消息,则判定该连接异常,断开超时连接。断开连接之前,心跳机制模块根据客户端初始发起连接时指定的CleanSession值决定是否保存会话状态。若CleanSession=0则保存会话状态,在下次重新连接时恢复会话状态,客户端就不用重新进行消息主题订阅等操作;否则,丢弃之前所有会话状态。
3 实验结果与分析
实验测试环境:一台部署CL2M系统中间件的服务器(Ubuntu12.04OS,IntelCorei5CPU,2.2GHz,8GBMemory)和若干台基于低温等离子体设备系统应用场景设计的产品嵌入式信息装置(PEID)[16]。
3.1 数据过滤有效性测试
为了测试设计的数据过滤算法对无效产品数据过滤的有效性,构建了200个产品主题消息匹配规则集和800个不匹配规则集,分别测试了在不同期望假阳性误判率下设计的CBF数据过滤的实际误判率,测试结果如表1所示。
表1 主题消息误判率测试结果
从测试结果表中可以看出,通过合理选择期望假阳性误判率和哈希函数个数k,能够有效保证较低的实际假阳性误判率,从而在允许一定误判率情况下有效实现无效数据过滤,满足实际应用需求。
3.2 实时性测试
图7 不同紧急性消息平均响应处理时间
从图7中可以看出随着数据服务订阅者个数的增加,中间件系统处理时间呈现上升态势。处理时间增加的根本原因是订阅者个数的增加导致中间件需要分发的产品数据量增大,但不同紧急性消息的平均处理时间都低于8.56s,系统响应时间能够满足实际应用需求。
另外,不同紧急性消息平均处理时间不同,紧急性高的消息平均处理时间明显低于紧急性低的处理时间。在订阅者为600时,星形曲线表示的高紧急性消息平均处理时间低于2.12s,菱形曲线表示的中等紧急性消息低于5.03s,方形曲线表示的普通消息低于8.56s。
3.3 吞吐率测试
大数量下,系统吞吐率是衡量CL2M系统中间件一项重要的性能指标,定义为单位时间内CL2M系统中间件能够成功处理和分发的数据包个数。为了测试吞吐率,3台PEID作为中间件客户端,向不同紧急性的3个产品主题(紧急消息、产品使用环境消息、普通消息)分别周期性发布100、500和500条产品主题消息。模拟紧急消息数据服务订阅者个数为100,环境消息和普通消息订阅者分别为300和200,对应共有26万条消息测试吞吐率。通过实际测试实验,约在130s内能够完成所有消息的处理和分发,吞吐率测试结果如图8所示。
图8 系统吞吐率
从图8可以看出在大数据量下,CL2M系统中间件能够维持较高的吞吐率,平均吞吐率约为2 162packets/s,满足CL2M系统应用要求,同时非常适合于传感器节点众多、数据量大的物联网环境下系统数据采集和分发基础中间件服务。
4 结 语
为了有效提供CL2M系统基础产品数据中间件服务,本文在分析CL2M系统中间件特点的基础上,结合物联网协议MQTT和非阻塞异步框架Netty设计了满足CL2M系统应用需求的基础数据服务中间件。通过最终实际测试表明,该中间件能够有效实现无效产品数据过滤,并具有良好的系统处理性能,因此也非常适合于扩展至传感器节点众多、数据量大的物联网环境下系统数据采集和分发基础中间件服务应用。
[1]MerinaMaharjan.EnablingClosedLoopLifecycleManagementwithInformationExchangeStandards[D].AaltoUniversity,2013.
[2]XinY,XintongZ.PLMforMultipleLifecycleProduct:Concepts,terminologies,processesforcollaborativeinformationmanagement[D].KTHRoyalInstituteofTechnology,2013,12.
[3] 徐亭.低温等离子体设备C-LPLM系统的研究与开发[D].合肥:中国科学技术大学,2015.
[4]KublerS,MadhikermiM,BudaA,etal.QLMmessagingstandards:introduction&comparisonwithexistingmessagingprotocols[M].ServiceOrientationinHolonicandMulti-AgentManufacturingandRobotics.SpringerInternationalPublishing,2014:237-256.
[5]CassinaJ,TaischM,PotterD,etal.DevelopmentofPROMISEarchitectureandPDKMsemanticobjectmodel[C]//ICEConferenceProceedings,2008:23-25.
[6]DimitrisKiritsis.Closed-loopPLMforintelligentproductsintheeraoftheInternetofthings[J].Computer-AidedDesign,2011(43):479-233.
[7]FrämlingK,NymanJ.Informationarchitectureforintelligentproductsintheinternetofthings[J].BeyondBusinessLogisticsProceedingsofNofoma,2008.
[8]JanAxelNyman.Productdatagatheringusingadistributedsoftwarearchitectureandproductembeddedinformationdevices[D].Espoo:HelsinkiUniversityofTechnology,2008.
[9]KaryFramling,SylvainKubler,AndreaBuda.UniversalMessagingStandardsfortheIoTFromaLifecycleManagementPerspective[J].IEEEInternetofThingsJournal,2014,1(4):319-327.
[10] 王旭,李文川.制造业的新理念—闭环产品生命周期管理[J].中国机械工程,2010,21(14):1687-1693.
[11] 刘刚.基于产品形态的生命周期数据闭环管理研究[D].济南:山东大学,2012.
[12] 王重楠,王宗陶,鲍忠贵,等.发布/订阅模式测控消息中间件系统设计[J].计算机应用,2015,35(3):878-881.
[13]MQTTVersion3.1.1.EditedbyAndrewBanksandRahulGupta.29October2014.OASISStandard[EB/OL].http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html.Latestversion:http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html.
[14] 谢鲲,文吉刚,张大方,等.布鲁姆过滤器查询算法[J].软件学报,2009,20(1):96-108.
[15]KirschA,MitzenmacherM.Lesshashing,sameperformance:BuildingabetterBloomfilter[J].RandomStructures&Algorithms,2005,33(2):187-218.
[16] 许宜春,徐亭,桑成.产品全生命周期数据自动采集PEID研制[J].计算机系统应用,2015,24(12):93-99.
DESIGN OF MIDDLEWARE IN CLOSED-LOOP LIFECYCLE MANAGEMENT SYSTEM FOR INTERNET OF THINGS
Cheng Jian Xu Yichun Sang Cheng
(CollegeofInformationScienceandTechnology,UniversityofScienceandTechnologyofChina,Hefei230027,Anhui,China)
In order to provide a more efficient data service in closed-loop lifecycle management system and solve the problem of interacting and sharing lifecycle information in many heterogeneous systems, a middleware based on MQTT and NIO framework Netty is proposed. Firstly, the connotation and architecture of closed-loop lifecycle management system are summarized briefly. Then, the architecture and process of the middleware are designed based on the analysis of characteristics of middleware in closed-loop lifecycle management system. Finally, an experiment is designed. Experimental results show that the middleware can quickly and efficiently implement invalid product data filtering. In the mode with mass data and data service subscribers, the average processing time of normal message keeps less than 8.56 s, and the average system throughput is 2 162 packets per second, which both meet the requriements of closed-loop lifecycle management data service. Meanwhile, the middleware is also well suitable for Internet of things with a large number of sensor nodes, implementing basic data collection and distribution service.
Closed-loop lifecycle management Message queue telemetry transport (MQTT) Netty Middleware Internet of things
2016-03-07。程健,高级工程师,主研领域:分布式网络测控技术及应用,智能仪器与自动检测技术,嵌入式系统(包括FPGA、DSP)及其应用,物联网环境下闭环生命周期管理系统。许宜春,硕士生。桑成,硕士生。
TP393
A
10.3969/j.issn.1000-386x.2017.04.004