物聯網智能數據采集和監測系統后臺服務設計研究

杜 渂 王聚全

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

0 引言

近年來，隨著物聯網智能設備大量的應用，針對物聯網智能設備數據采集和監控系統的需求也越來越多，基于這樣的市場需求，筆者所在的研發團隊研發了一款基于物聯網的智能數據采集設備和相對應的數據采集和監控系統。

本單位研發的物聯網智能數據采集和監控系統，以物聯網智能終端設備為基礎應用設備，通過物聯網數據采集設備進行數據采集，以計算機網絡為通信平臺，將本單位研發的物聯網智能數據采集和監控系統作為上層應用，實現各種智能終端設備的統一接入、統一數據采集、統一監控。

本文將介紹基于物聯網的智能數據采集和監控系統在后臺服務上的一些設計方法。

1 設計理念

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

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

圖1 通過配置實現解耦的架構體系

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

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

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

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

2 服務設計方法

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

2.1 業務模型層的設計

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

基礎模型定義了系統中所有類的基類。

設備模型定義了物聯網數據采集設備及終端設備的層次結構、設備屬性、設備中測點的屬性、ModbusTCP消息解析協議和數據轉換協議等內容，同時對物聯網數據采集設備與終端設備的消息收發與解析進行相應的操作。設備模型中還定義了設備的監控過程，包括消息的發送、接收、解析、數據轉換、采集的數據是否在正常范圍內、異常事件通知等業務邏輯。設備模型是業務模型層的核心模型，也是整個系統的基礎。

圖2 后臺服務模型圖

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

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

業務模型層的消息解析結構如圖3所示。

圖3 業務模型層消息解析圖

2.2 解析層的設計

解析層架構由ModbusTCP消息解析器、數據轉換器及XML解析器三部分組成，主要用于對消息的解析及XML配置文件的讀取解析。

（1）ModbusTCP消息解析器

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

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

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

（2）數據轉換器

數據轉換器主要針對智能設備每個測點采集的監測數據進行數據轉換使用，轉換器可以配置參數并進行擴展。

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

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

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

轉換器累加串聯結構如圖4所示。

圖4 轉換器串聯結構圖

（3）配置解析器

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

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

3 配置解析器的設計

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

圖5 調用解析器/轉換器過程圖

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

圖6 定參過程圖

4 配置解析器的解析流程

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

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

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

圖7 XML配置文件解析方法

（1）資源層的設計

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

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

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

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

圖8 主題工廠關系圖

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

圖9 主題映射關系圖

（2）通信層的設計

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

通過構建通信適配器插件的方式也可擴展通信層支持的協議類型。

（3）業務公共層的設計

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

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

5 結束語

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

[1] 杜渂，王聚全，雷霆，基于物聯網的智能數據采集和監控系統設計[J].電信快報，2013（7）：14-17.

[2] 杜渂，基于RFID技術的公共交通調度系統開發與應用[J].電信快報，2010（6）：10-13，18.