面向物聯網的閉環全生命周期管理系統中間件設計

程 健 許宜春 桑 成

(中國科學技術大學信息科學技術學院 安徽 合肥 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