杜 渂 王聚全

（1.上海迪愛斯通信設備有限公司 上海 200030 2.電信科學技術(shù)第一研究所 上海 200032）

0 引言

近年來，隨著物聯(lián)網(wǎng)智能設備大量的應用，針對物聯(lián)網(wǎng)智能設備數(shù)據(jù)采集和監(jiān)控系統(tǒng)的需求也越來越多，基于這樣的市場需求，筆者所在的研發(fā)團隊研發(fā)了一款基于物聯(lián)網(wǎng)的智能數(shù)據(jù)采集設備和相對應的數(shù)據(jù)采集和監(jiān)控系統(tǒng)。

本單位研發(fā)的物聯(lián)網(wǎng)智能數(shù)據(jù)采集和監(jiān)控系統(tǒng)，以物聯(lián)網(wǎng)智能終端設備為基礎應用設備，通過物聯(lián)網(wǎng)數(shù)據(jù)采集設備進行數(shù)據(jù)采集，以計算機網(wǎng)絡為通信平臺，將本單位研發(fā)的物聯(lián)網(wǎng)智能數(shù)據(jù)采集和監(jiān)控系統(tǒng)作為上層應用，實現(xiàn)各種智能終端設備的統(tǒng)一接入、統(tǒng)一數(shù)據(jù)采集、統(tǒng)一監(jiān)控。

本文將介紹基于物聯(lián)網(wǎng)的智能數(shù)據(jù)采集和監(jiān)控系統(tǒng)在后臺服務上的一些設計方法。

1 設計理念

早期的智能設備采集和監(jiān)控系統(tǒng)，采用的設計理念是針對每個智能設備編寫一個采集和監(jiān)控程序。這樣的設計方式不易動態(tài)增加設備，在開發(fā)上導致每一個設備的采集和監(jiān)控程序都需要控制通信、轉(zhuǎn)換和容錯等處理功能。同時，新增加的采集監(jiān)控程序需要下載到數(shù)據(jù)采集設備中，并進行調(diào)試和測試，上位機系統(tǒng)也需要增加相應功能的采集和監(jiān)控程序。

基于物聯(lián)網(wǎng)的智能數(shù)據(jù)采集和監(jiān)控系統(tǒng)，實現(xiàn)了各種智能終端設備的統(tǒng)一接入、統(tǒng)一數(shù)據(jù)采集和統(tǒng)一監(jiān)控。系統(tǒng)在服務設計上采用了通過配置實現(xiàn)解耦的設計思想，將面向設備的設計理念通過多層抽象、解耦和協(xié)議轉(zhuǎn)換，轉(zhuǎn)變成編寫設備協(xié)議轉(zhuǎn)換規(guī)則的模式，使得智能設備可以通過配置的方式快速接入到系統(tǒng)，如圖1所示。解決了不同廠商、不同功能的智能終端設備的接入問題，大大提高了系統(tǒng)的實施效率和可擴展性。

圖1 通過配置實現(xiàn)解耦的架構(gòu)體系

通過這種設計方式，在產(chǎn)品化方面，通過配置即可達到接入大部分智能設備的功能。通過多層抽象，編寫通用的業(yè)務模型組件、通信協(xié)議組件和協(xié)議轉(zhuǎn)換組件，將設備數(shù)據(jù)交互抽象成為某一數(shù)據(jù)轉(zhuǎn)換協(xié)議，通過配置協(xié)議轉(zhuǎn)換組件達到接入大部分智能設備的功能。

在可擴展方面，針對某些使用自定義協(xié)議的智能設備或者無法通過配置協(xié)議轉(zhuǎn)換規(guī)則接入的智能設備，可以采用編寫應用插件的方式進行擴展。應用插件采用對協(xié)議轉(zhuǎn)換規(guī)則進行抽象封裝，使得以后使用同種協(xié)議模式的智能設備的不需要再進行開發(fā)即可方便的接入到系統(tǒng)中。

在開發(fā)復雜度方面，數(shù)據(jù)采集設備內(nèi)不需要編寫復雜的智能設備接入程序，僅需下載配置好的解析文件即可采集智能設備的各種數(shù)據(jù)，使得采集設備內(nèi)的嵌入式軟件開發(fā)復雜度降低。同時，業(yè)務模型層－解析層－視圖模型層－界面層等各層之間業(yè)務和數(shù)據(jù)進行了解耦，各層之間通過配置后的協(xié)議轉(zhuǎn)換組件進行通信和解析，使得監(jiān)控系統(tǒng)開發(fā)的復雜度降低。由于采用了統(tǒng)一框架的模式，由系統(tǒng)框架來統(tǒng)一處理各種設備的數(shù)據(jù)、通信和界面顯示等異常情況，使得定制開發(fā)和插件開發(fā)的復雜度降低。

在實施過程中，由于采用動態(tài)界面的設計模式，使得界面上所有展現(xiàn)組件可根據(jù)使用場景隨意添加和布局。針對大部分設備，由工程人員通過配置化操作即可實施，降低了項目實施的復雜度。

2 服務設計方法

系統(tǒng)后臺服務主要由業(yè)務模型層、解析層、資源層、通信層和公用模塊組成，本章主要通過介紹業(yè)務模型層、解析層和資源層的設計思想，描述可配置的智能設備接入方案的實現(xiàn)原理。系統(tǒng)的各層模型如圖2所示。

2.1 業(yè)務模型層的設計

業(yè)務模型層主要用來描述業(yè)務的基礎模型和設備模型，也包含了監(jiān)控相關(guān)的流程。業(yè)務模型層主要由三部分組成，分別是基礎模型、設備模型和業(yè)務模型層配置化消息解析功能。

基礎模型定義了系統(tǒng)中所有類的基類。

設備模型定義了物聯(lián)網(wǎng)數(shù)據(jù)采集設備及終端設備的層次結(jié)構(gòu)、設備屬性、設備中測點的屬性、ModbusTCP消息解析協(xié)議和數(shù)據(jù)轉(zhuǎn)換協(xié)議等內(nèi)容，同時對物聯(lián)網(wǎng)數(shù)據(jù)采集設備與終端設備的消息收發(fā)與解析進行相應的操作。設備模型中還定義了設備的監(jiān)控過程，包括消息的發(fā)送、接收、解析、數(shù)據(jù)轉(zhuǎn)換、采集的數(shù)據(jù)是否在正常范圍內(nèi)、異常事件通知等業(yè)務邏輯。設備模型是業(yè)務模型層的核心模型，也是整個系統(tǒng)的基礎。

圖2 后臺服務模型圖

系統(tǒng)中所有消息解析的規(guī)則都是在XML文件中進行配置的，包括消息的解析、消息變量的解析和數(shù)據(jù)轉(zhuǎn)換等，現(xiàn)系統(tǒng)主要包含了對ModbusTCP協(xié)議的01和03消息的解析。針對每種消息類型，設計有相應的消息解析器，如果需要解析其它的消息類型，可以采用開發(fā)消息解析插件的方式編寫相應的解析器類，并在XML中進行配置，動態(tài)加載使用。

通過配置化的解析過程，使得系統(tǒng)能夠靈活適應不同設備的監(jiān)控需求。當現(xiàn)有系統(tǒng)中的轉(zhuǎn)換器不能滿足要求，也可以通過編寫轉(zhuǎn)換器插件進行擴展，并在XML文件中配置后動態(tài)加載使用。

業(yè)務模型層的消息解析結(jié)構(gòu)如圖3所示。

圖3 業(yè)務模型層消息解析圖

2.2 解析層的設計

解析層架構(gòu)由ModbusTCP消息解析器、數(shù)據(jù)轉(zhuǎn)換器及XML解析器三部分組成，主要用于對消息的解析及XML配置文件的讀取解析。

（1）ModbusTCP消息解析器

ModbusTCP消息解析器用于對ModbusTCP消息的封裝和解析，現(xiàn)包含01和03消息的解析器插件，針對業(yè)務上的需求，可以通過擴展插件的方式進行解析器的擴展。

ModbusTCP 01/03消息解析需要對字節(jié)流按照ModbusTCP協(xié)議分解為7個字節(jié)的消息頭，并根據(jù)功能碼是否正常保存相關(guān)數(shù)據(jù)，返回解析后的消息包。功能碼如果收發(fā)消息一致則正常，如果接收的消息功能碼是發(fā)送消息功能碼加上0x80，則表示消息異常，程序中需要保存錯誤信息。

01/03消息封裝需要將上層的消息包按照ModbusTCP協(xié)議填充到字節(jié)流中，需要注意的是由于協(xié)議中規(guī)定需要按照Big Endian方式傳遞消息，故在填充時需要將數(shù)據(jù)按照這種方式來轉(zhuǎn)換，最后生成包含字節(jié)流和原始功能碼的發(fā)送消息包。在設計時考慮將原始功能碼封裝到包中是為了達到判斷接收消息中的功能碼是否正常的目的。

（2）數(shù)據(jù)轉(zhuǎn)換器

數(shù)據(jù)轉(zhuǎn)換器主要針對智能設備每個測點采集的監(jiān)測數(shù)據(jù)進行數(shù)據(jù)轉(zhuǎn)換使用，轉(zhuǎn)換器可以配置參數(shù)并進行擴展。

01/03消息數(shù)據(jù)轉(zhuǎn)換過程實際上涉及到模型層中定義的接收消息處理流程。對于01消息只需要將字節(jié)流轉(zhuǎn)化為位數(shù)組，采用默認的ByteToBitConverter轉(zhuǎn)換器即可實現(xiàn)。03消息較復雜，需要根據(jù)每個設備測點在字節(jié)流中的位置先將字節(jié)流中的數(shù)據(jù)分離出來，再根據(jù)每個測點對應的數(shù)據(jù)轉(zhuǎn)換器數(shù)組進行依次的數(shù)據(jù)轉(zhuǎn)換。兩種消息在數(shù)據(jù)轉(zhuǎn)換完成時，都需要進行數(shù)據(jù)的效驗，最終進行測點賦值。

由于需要監(jiān)控的終端設備千變?nèi)f化，每種設備的測點數(shù)據(jù)在從物聯(lián)網(wǎng)數(shù)據(jù)采集設備中獲得時可能還不能直觀的顯示給用戶，因此需要做一定的轉(zhuǎn)換。例如從溫濕度計獲得的數(shù)據(jù)可能并不是攝氏度的方式表達的，就需要轉(zhuǎn)換為攝氏度。在轉(zhuǎn)換的過程中，系統(tǒng)提供了相應的數(shù)據(jù)轉(zhuǎn)換器對測點數(shù)據(jù)進行處理。但由于轉(zhuǎn)換過程的不定性，不可能窮盡所有的轉(zhuǎn)換方式，在設計時可以將一些轉(zhuǎn)換方式分解，然后根據(jù)實際需求采用多個轉(zhuǎn)換器累加串聯(lián)的模式，即上一個轉(zhuǎn)換器得到的結(jié)果將被應用于下一個轉(zhuǎn)換器，使用多個轉(zhuǎn)換器來實現(xiàn)同一個數(shù)據(jù)的轉(zhuǎn)換，并獲得最終的結(jié)果，實現(xiàn)了更多的轉(zhuǎn)換功能。

針對業(yè)務上特殊的需求，用現(xiàn)有的轉(zhuǎn)換器無法對數(shù)據(jù)進行有效轉(zhuǎn)換的話，可以以開發(fā)插件的方式新編寫一個或多個轉(zhuǎn)換器來應對出現(xiàn)的特殊轉(zhuǎn)換，當然在研發(fā)時需要盡量進行抽象設計，保證新的轉(zhuǎn)換器能被應用到新的場合。這種方式通過使用多個轉(zhuǎn)換器就能對復雜的數(shù)據(jù)進行轉(zhuǎn)換并獲得結(jié)果，最大程度的復用了轉(zhuǎn)換器，并通過使用不同的轉(zhuǎn)換器參數(shù)還能完成同一個轉(zhuǎn)換器的不同功能。相對應的，在XML配置時則需要對每個測點配置多個轉(zhuǎn)換器，配置順序決定了轉(zhuǎn)換器執(zhí)行的順序。

轉(zhuǎn)換器累加串聯(lián)結(jié)構(gòu)如圖4所示。

圖4 轉(zhuǎn)換器串聯(lián)結(jié)構(gòu)圖

（3）配置解析器

配置解析器用于所有XML配置文件的解析與驗證，同時支持解析器的擴展。

配置解析過程包括：加載XML配置文件，解析XML配置文件根元素，根據(jù)根元素獲取對應的解析器，并進行XML配置文件架構(gòu)驗證，最后再使用解析器解析XML配置文件獲得對應對象。如果解析器在解析配置的過程中，該XML配置文件還關(guān)聯(lián)了其它XML配置文件，則會對關(guān)聯(lián)的所有XML配置文件進行再解析。系統(tǒng)中的XML配置文件是從第一個主XML文件開始，將所有XML文件關(guān)聯(lián)起來的，因此只需要調(diào)用一次加載方法即可將所有的XML配置文件加載起來。

3 配置解析器的設計

在配置解析器設計中采用的是工廠模式的設計方法。一般的工廠模式是將選擇權(quán)交給工廠，本系統(tǒng)則將選擇權(quán)配置在XML文件中。每種類型的工廠存儲了該類型相關(guān)的解析器或轉(zhuǎn)換器，對應于相應的XML配置。同時工廠中的每個解析器或轉(zhuǎn)換器的ID又被其它XML文件引用，從而確定了運行時需要的具體對象類型。這樣的方式類似于IoC，能夠?qū)㈩愔g的依賴放在配置中而不是代碼中，有利于修改和擴展功能。調(diào)用解析器/轉(zhuǎn)換器過程如圖5所示。

圖5 調(diào)用解析器/轉(zhuǎn)換器過程圖

在定義解析器或轉(zhuǎn)換器的同時，也可以定義其默認參數(shù)和用戶參數(shù)。默認參數(shù)是在工廠對應的XML文件中定義的，屬于出廠時的參數(shù)，在其它XML引用工廠中對象時，可以更改默認參數(shù)為實際的用戶參數(shù)，最終使用的參數(shù)將是這兩種參數(shù)的組合，其中用戶參數(shù)優(yōu)先。默認參數(shù)和用戶參數(shù)的定參過程如圖6所示。

圖6 定參過程圖

4 配置解析器的解析流程

XML配置文件的解析實際上采用了兩種方式：一種是自解析，即XML根元素已經(jīng)描述了如何解析該XML文件，主要包含創(chuàng)建解析器需要使用的程序集和對象類型，以及架構(gòu)驗證需要的文件路徑。另一種是通過根元素名稱在XML解析器工廠對應的XML文件中進行匹配。分別使用這兩種方式的原因在于，第二種方式的使用前提是XML解析器工廠已經(jīng)從XML文件中加載起來，這樣該工廠對應的這個XML就必須要先完成自解析，即第一種方式是第二種方式的前提。

采用根元素來匹配的方式也簡化了系統(tǒng)中的判斷流程，根元素名稱決定了該XML的類型和所使用的解析器類型。同時這種設計方法可以在解析XML配置文件的時候重用，例如系統(tǒng)中大部分的數(shù)據(jù)字典在XML結(jié)構(gòu)上都是一樣的，所以只需要采用同一個根元素名稱，就能使用同一個解析器進行解析，不需要再增加額外的解析器。

系統(tǒng)在解析時還采用了XML架構(gòu)文件來驗證XML的結(jié)構(gòu)正確性，這樣設計的目的是為了簡化程序代碼中對XML的效驗，同樣每個根元素名稱也對應唯一一個XML架構(gòu)文件。XML配置文件解析方法如圖7所示。

圖7 XML配置文件解析方法

（1）資源層的設計

資源層主要包含了系統(tǒng)需要使用的相關(guān)資源，包含了界面需要使用的控件庫、容器庫、監(jiān)控主題、配置需要使用的模板字典、加載XML配置文件的統(tǒng)一入口信息，以及系統(tǒng)需要使用的數(shù)據(jù)類型和字典資源。

資源層供其它模塊和層次調(diào)用，也采用類似解析層使用的工廠模式設計方法進行設計，可進行資源的配置、擴展和替換。

資源層最主要的應用場景是使用監(jiān)控主題，監(jiān)控主題主要是將所監(jiān)控的各個設備以及設備上的各個測點依據(jù)用戶的需求動態(tài)組合在一個監(jiān)控界面中，并結(jié)合布局進行動態(tài)展示。

監(jiān)控主題主要由主題、主題映射及自定義主題三個部分組成，其中主題用于展示界面需要顯示的監(jiān)控內(nèi)容，由主題工廠、主題、布局容器和前端展現(xiàn)控件組成。主題工廠層次如圖8所示。

圖8 主題工廠關(guān)系圖

主題映射是主題與界面對象之間的映射關(guān)系，通過映射關(guān)系可關(guān)聯(lián)到主題集合，進而可關(guān)聯(lián)到每個主題，使得前臺界面層能依據(jù)主題映射關(guān)系動態(tài)加載用戶需要展現(xiàn)的主題。主題映射層次如圖9所示。

圖9 主題映射關(guān)系圖

（2）通信層的設計

通信層主要用于建立ModbusTCP連接，可同步或異步收發(fā)ModbusTCP消息。通信層的核心為通信適配器，通過通信適配器可以同其它支持ModbusTCP協(xié)議的設備建立連接和收發(fā)消息（ModbusTCP協(xié)議默認端口為502）。

通過構(gòu)建通信適配器插件的方式也可擴展通信層支持的協(xié)議類型。

（3）業(yè)務公共層的設計

公共層主要包含通用輔助類庫、異常中心及系統(tǒng)配置模塊。

通用輔助類用于定義系統(tǒng)使用的一些通用方法和信息。異常中心用于記錄異常的日志信息以及發(fā)出異常通知消息。系統(tǒng)配置模塊用于讀取和保存系統(tǒng)中使用的各種配置項。

5 結(jié)束語

本文結(jié)合物聯(lián)網(wǎng)智能數(shù)據(jù)采集和監(jiān)控系統(tǒng)實際應用需求，通過對該系統(tǒng)后臺服務設計理念和架構(gòu)設計的論述，闡述了該系統(tǒng)的研究設計成果，對構(gòu)建具有良好的擴展能力、高性能和易實施的物聯(lián)網(wǎng)智能數(shù)據(jù)采集和監(jiān)控系統(tǒng)具有一定的指導意義。通過使用該系統(tǒng)，可以顯著降低研發(fā)人員工作量，縮短項目履行人員實施周期，提高工作效率和提升項目質(zhì)量，具有良好的應用價值和前景。

[1] 杜渂，王聚全，雷霆，基于物聯(lián)網(wǎng)的智能數(shù)據(jù)采集和監(jiān)控系統(tǒng)設計[J].電信快報，2013（7）：14-17.

[2] 杜渂，基于RFID技術(shù)的公共交通調(diào)度系統(tǒng)開發(fā)與應用[J].電信快報，2010（6）：10-13，18.