【長文乾貨】工業物聯網通訊框架 ServerSuperIO 的實踐應用

02-08

物聯網、大數據、雲計算作為新一代信息技術，吸引著越來越多的關注。人們對其的研究，常常局限於其中某一個領域。事實上，我們應該將物聯網、大數據、雲計算看作現實系統體系化建設的三個方面，整體而視之。物聯網是以智能感測器為基礎的網路化建設，對大量感測器的實時感知和控制必然會產生大量的數據，而對特定行業的這些數據集合進行數學模型分析必然會產生巨大的現實意義。

工業互聯網現實系統體系建設的三個方面

當前，大數據、雲服務等成為行業關注的焦點。事實上，基礎物聯網建設同樣重要，它是系統體系化建設的根基，這一點在工業領域尤為明顯。所以，針對現階段物聯網建設中高可用、高擴展性通訊框架的應用，有很大的現實意義和發展空間。

要發展物聯網建設首先要加深對於現實世界的認知，目前一些特定行業並不具備物聯的基礎條件，物聯網建設困難重重；而對於具備物聯網建設基礎的行業來說，也存在著諸多現實問題，如設備多樣性、協議多樣性、通訊機制多樣性、數據多樣性等，但這也恰恰證明物聯網的發展有廣闊的市場空間。

工業物聯網具備四個多樣性

當前，許多大型企業都相繼建立了雲平台，制定協議標準，但對傳統企業來說，市場競爭激烈，在短時間內完全統一更新換代困難較大。當前，用框架性的東西去解決設備多樣性、協議多樣性、通訊機制多樣性、數據多樣性的問題，是物聯網和集成系統的建設中的一種手段，可以先解決企業互聯監控的問題，再解決企業標準化的問題。

不同思維方式的整合資源方法

要解決細節問題，不能用細節的思維方式去解決，而應運用結構化思路解決問題。網關層、服務端是否可以使用同一套框架？框架之間是否可以無縫對接？如果可以實現，應用同一套框架，開發效率會大大提高，人力成本和時間成本也會降低。好的組織結構、好的框架要解決效率和成本的問題，否則就失去了任何價值。

降本增效示意圖

ServerSuperIO就是以這樣的一種思維方式演變而來，ServerSuperIO不僅僅是通訊框架，更是一個物聯網框架，首先是以設備（感測器）為核心構建的框架，設備（感測器）的協議無關性，可以隨意掛載設備驅動在框架下運行。所以ServerSuperIO本質上協調設備驅動（協議）、IO通道（COM和NET）、運行機制（模式）之間的協調機制，使之無縫結合、運行。框架具備如下特點：

輕型高性能通信框架，適用多種應用場：包括輪詢模式、自控模式、併發模式、單例模式等。
支持協議驅動器，可以按規範寫標準協議和自定義協議。
支持發送數據緩存器，支持命令緩存重發和按優先順序別發送。
支持協議過濾器，按規則篩選數據，並且可以承繼介面，自定義過濾方式。
支持接收數據緩存器，可以緩存不符合過濾器的數據，和下次接收數據進行拼接。
支持按設備命令優先順序別進行調度設備，保證有高級別命令的驅動及時發送。
支持一個設備驅動，同時支持串口和網路兩種通訊方式，可以監視IO通道數據。
支持一個設備驅動，在網路通訊時可以支持TCP Server和TCP Client兩種工作模式。
支持多設備共享同一IO通道進行通訊。
支持定時清理超時的網路IO通道。
支持顯示視圖介面，滿足不同人機對話的需求。
支持服務組件介面，例如：4-20mA輸出、LED大屏顯示、簡訊服務、以及多功能網關服務。
設備驅動與設備驅動，設備驅動與伺服器（雲端）可以實時雙向交互，上傳數據和指令下發。
支持OPC Server服務。
支持創建多服務實例，完成不同業務的拆分。
支持跨平台部署，可以運行在Linux和Windows系統。

通訊機制

有些人認為通訊很簡單，打開連接之後發送、接收數據就可以了。但是把複雜的情況考慮全面，並非易事。對於實時數據採集框架，通訊部分始終是軟體的核心，要求高實時性、高穩定性、高擴展性。軟體框架決定了軟體運行的穩定性，以及以後的擴展性，所以需要對通訊機制、控制方式進行良好的設計。

所以決定了軟體框架在通訊方面有兩種應用方式：主動請求和被動接收。

主動請求方式又可以稱之為呼叫應答方式或主從方式。主動權在軟體框架端，只有軟體框架主動發送請求命令，從機（硬體設備、感測器等）接收到命令後並且檢驗數據的完整性，以及確定是否發給自己的命令，校驗成功後，返回指定的數據信息，完成一次完整的鏈路通訊過程。呼叫應答通訊方式，如下圖所示：

呼叫應答通訊方式

在複雜的應用場景中，這兩種通訊方式都有可能存在，此類情況一般是採用乙太網鏈路進行通訊。針對只有外接串口的設備可以通過乙太網轉換模塊來接入。

輪詢通訊機制

這是框架最早的運行模式，串口和網路通訊時都可以使用這種控制模式。當有多個設備連接到通訊平台時，通訊平台會輪詢調度設備進行通訊任務。某一時刻只能有一個設備發送請求命令、等待接收返回數據，這個設備完成發送、接收（如果遇到超時情況，則自動返回）後，下一個設備才進行通訊任務，依次輪詢設備。

應用場景是這樣的，服務端與設備進行通訊遵循呼叫應答的方式，也就是IO可用的情況下，服務端先發起通訊命令請求，設備根據命令信息，檢驗通過後返回數據給服務端。這種通訊模式很好理解，每個設備的通訊都遵循排隊的原則。但是如果某個設備的命令需要及時發送，怎麼辦？ServerSuperIO框架是支持設備優先順序別調度的，例如：對某個設備要進行實時的檢測，需要連續發送命令，那麼就需要對設備進行高級別設置，發送請求數據命令。

通訊結構如下圖：

開發通訊機制

網路通訊的情況下，輪詢模式顯然效率比較低，那麼可以採用併發模式。並發通訊模式是集中發送給所有設備請求指令，框架是採用循環同步方式發送請求命令給每個IO通道對應的設備，當然也可以採用並行非同步方式集中發送請求命令。硬體設備接收到指令後進行校驗，校驗成功後返回對應指令的數據，通訊平台非同步監聽到數據信息後，進行接收操作，然後再進行數據的分發、處理等。

那麼這裡就涉及到IO通道接收到的數據是非同步接收的，如何才能和設備驅動匹配上（把數據分發到設備驅動上），這是能過DeviceCode和DeviceIP兩種方式來實現的。DeviceCode可以是設備地址或是設備編碼，DeviceIP是預先設置好的參數，要求終端設備的IP地址是固定的。

通訊結構如下圖：

自控通訊機制

只有網路通訊時可以使用這種控制模式。自控通訊模式與並發通訊模式類似，區別在於發送指令操作交給設備驅動本身進行控制，或者說交給二次開發者，二次開發者可以通過時鐘定時用事件驅動的方式發送指令數據。硬體設備接收到指令後進行校驗，校驗成功後返回對應指令的數據，通訊平台非同步監聽到數據信息後，進行接收操作，然後再進行數據的分發、處理等。

自控通訊模式可以為二次開發者提供精確的定時請求實時數據機制，使通訊機制更靈活、自主，如果多個設備驅動共享使用同一個IO通道的話，時間控制會有偏差。

同樣涉及到數據的分發，和併發模式一樣。

通訊結構如下圖：

單例通訊機制

只有網路通訊時可以使用這種控制模式。在一個服務實例內只能有一個設備驅動，相當於一個設備驅動對應著N多個硬體設備終端。更適合通訊的數據協議有固定的標準，以命令關鍵字處理不同的數據。適用於高並發的硬體終端設備主動上傳數據，伺服器端根據數據信息進行處理和返回相應的數據。

通訊結構如下圖：

「感測器」驅動的插件化應用

插件技術是在軟體的設計和開發過程中，將整個應用程序劃分為宿主程序和插件對象兩部分，宿主程序能夠調用插件對象，插件對象能夠在宿主程序上實現自己的邏輯，而兩者的交互基於一種公共的通信契約。宿主程序可以獨立於插件對象存在，即使沒有任何插件對象，宿主程序的運行也不受影響，因此，我們可以在避免改變宿主程序的情況下通過增減插件或修改插件的方式增加或調整功能。由於使用了插件技術的宿主程序具備了一個框架的本質特徵，因此可以將它看作是一種插件式框架。插件式框架能夠有效地降低功能對象與對象管理邏輯之間的耦合程度，並將耦合置於最優的程度。

一個框架使用插件機制的原因主要基於以下3點：

可以在無需對程序進行重新編譯和發布的條件下擴展程序的功能。
可以在不需要程序源代碼的環境下為程序增加新的功能。
在一個程序的業務邏輯不斷發生改變、新的規則頻頻加入時能夠靈活適應。

實現插件機制一般有3種技術：基於動態連接庫DLL的插件、基於組件對象模型COM的插件、以及基於.NET反射技術的插件。ServerSuperIO是使用.NET反射技術實現的插件機制。

插件式框架的宿主程序啟動後，它首先會載入相應的配置文件（例如：設備驅動配置文件等），找到相應的插件程序集，這些程序集以DLL文件格式存在，框架的宿主程序會找到指定的插件類型，由插件引擎依據插件類型（例如：IRunDevice）生成對象實例，由框架的宿主程序的管理器對插件實例進行管理和調度。

一個插件程序集可能包括多個插件類型，那麼框架宿主程序是如何識別這些類型是否為要載入的插件呢？每個插件對象都有一個身份標識－介面，這個標識在框架設計中被稱為「通訊契約」。介面可以被看作是一種定義了必要的方法、屬性和事件的集合，因此宿主程序就可以通過這種契約來生成具體的實例對象，並對其他組件或介面公開可操作的對象。

插件式框架作為一個高聚合低耦合的平台，它的功能定義與功能實現之間是分離的。只要符合插件規範的二次開發組件都可以掛載到框架平台中，而它並不關心這些組件的具體功能。當然，框架平台提供了一些必要的信息、機制來保證這些組件能夠正常實現二次開發的功能。

在具有多個邏輯層次的結構設計中，各層之間的通信大多通過介面來實現，介面不會輕易改變，如果一個層的功能發生變化，不會影響其他層；只要正常實現了介面的組件功能，那麼程序的運行就沒有問題。這種做法使得各層之間的相互影響降低到最低，總之，介面在多業務層級中能夠更好的解耦，所以每個設備驅動都可以有自己的業務邏輯。

可掛載的設備驅動信息在配置文件中進行標註，當掛載新的設備驅動的時候，如增加設備，就會從這個配置組中載入信息，以便操作人員進行選擇。設備驅動配置信息定義如下圖：

當調用增加設備驅動窗體的時候會從配置文件讀取程序集信息，以完成增加設備驅動，並且在ServerSuperIO框架下運行。

一套驅動同時支持多種IO鏈路

作為物聯網通訊框架平台軟體，IO是核心部分之一，涉及到與硬體設備、軟體之間的信息數據交互，主要包括兩部分：IO實例與IO管理器。IO實例負責直接對串口和網路進行操作；IO管理器負責對IO實例進行管理。

框架平台一大特點就是開發一套設備驅動（插件）同時支持串口和網路兩種通訊方式，而兩種通訊方式的切換隻需要改動配製文件。

不同的設備類型和協議、不同的通訊方式，用堆代碼的方式進行開發，根本無法適應不同場景的應用，提高了代碼的維護成本，以及修改代碼可能造成潛在的BUG，是讓人很頭疼的一件事。

在開始設計框架平台的時候，一個核心的思想就是把變的東西要設計靈活，把不變的東西設計穩定。對於設備的協議就是變的東西，對於IO部分就是相對不變的東西，那就需要對串口IO和網路IO進行整合。不僅在代碼層面要運行穩定；在邏輯層面，不管是串口IO還是網路IO在框架內部是統一的介面，所有對IO的操作都會通過這個統一的介面來完成。

示意如下圖：

數據過濾器，解決一包多發、粘包、冗餘數據

一包多發及解決

多包發送數據是應用環境中的一種情況或一個問題，並不是我們會這樣實際應用，而是說在接收過程中多次接收數據才能完整接收客戶端一次發送的數據，可能由於網路環境或發送數據端造成的，示意如下圖：

例如實時數據的完整包為：55 AA 00 61 43 7A 00 00 43 B4 15 0D。那麼接收數據的時候，第一次接收到：55 AA 00 61 43 7A 00 00 43 B4 15，第二次接到：0D。按通訊協議應該能夠把這兩次接收的數據進行自動拼接，形成完整的數據並進行解析2。

粘包及解決

在通訊領域中是經常會遇到的問題。也就是多包數據一次性的接收，那麼就要合理的進行拆包。還有一種情況，就是多包半的數據一次性的接收，那半包的數據結合「1.一包多發及解決」來解決這個問題，示意如下圖：

冗餘數據的出現及解決

受電纜或環境的電磁干擾，以及接頭虛接等，這種情況極有可能出現。如果幹擾的冗餘數據夾雜在一個協議包中間，那麼校驗出合法的數據很困難。如果幹擾的冗餘數據夾雜在兩個協議包中間，那麼就可以通過協議過濾來實現識別出有用的數據。示意如下圖：

綜合解決上述問題，ServerSuperIO支持5種數據過濾器：

FixedEndReceiveFliter：固定結尾的協議過濾器。
FixedHeadAndEndReceiveFliter：固定開頭和結尾的協議過濾器。
FixedHeadAndLengthReceiveFliter：固定開頭和長度的協議過濾器。
FixedHeadReceiveFliter：固定開頭的協議過濾器。
FixedLengthReceiveFliter：固定長度的協議過濾器。

這5個過濾器都繼承自IReceiveFilter介面，也可以繼承這個介面進行二次開發，定製自己的協議過濾器。代碼工程如下圖：

感測器之間、感測器與雲端的交互

物聯網建設中數據採集是基礎，進行控制是目的，這是兩個根本要素。在採集設備數據的時候，如果該設備的實時數據出現異常，那麼是否存在其他設備要進行聯動？也就是說一個設備出現異常之後，要對其他某個設備進行聯動控制，以達到避免出現更大危險的情況。

那麼不僅要對某個設備進行聯動控制，還要對控制的結果進行反饋給出現異常的設備。形成異常、聯動、控制、反饋的閉環，以達到監測與控制共同作用的目的。

如果單單是採集硬體的數據與控制，也只能算是本地的系統，但是在物聯網和集成系統建設中，必須形成體系化、網路化框架。所以ServerSuperIO在採集本範圍內的數據信息與控制外，還要形成與上一級的ServerSuperIO進行數據交互，以及接收下一級的ServerSuperIO的交互數據，那麼ServerSuperIO之間就形成了級聯的關係，主要完成兩大職責：數據的級聯上傳和反向控制，進而對設備本身進行級聯控制。

結構示意圖如下：

感測器之間的交互、控制

採集與控制單個設備，在實際應用中還遠遠不夠，還要能夠設備與設備之間進行信息傳遞與控制，並且返回給發送控制源設備確認信息。例如：在監測流量計嚴重報警的情況下，是否應該調節或控制液體源頭的閥門。類似的例子很多。

ServerSuperIO支持設備向另一個設備發起傳遞信息和控制後，被控制設備是否立即返回確認信息，還是自主非同步決定返回確認信息。增加了非同步返回確認信息的功能，因為控制命令只是發給了另一個設備驅動，設備驅動還會進一步與實際的硬體設備進行交互，與實現硬體交互成功後，再返回確認信息給發起的源設備驅動。

示意圖如下：

感測器與雲端的交互、控制

ServerSuperIO提供了服務驅動的介面，一些除設備驅動類的功能以外，都可以以服務驅動的方式存在，例如：多設備採集的數據的融合模型計算、與其他平台或上層進行交互等等，在此僅以與服務端進行交互為實例進行介紹。與設備驅動之間的交互與控制不同的是，設備驅動主動把採集的數據信息傳遞給服務驅動，服務驅動與雲端進行交互，在接收雲端指令後，發起傳遞信息或控制設備驅動，設備驅動再返回確認信息給服務驅動。

示意圖如下：

與OPC Server的對接

OPC(OLE for Process Control, 用於過程式控制制的OLE)是一個工業標準，基於微軟的OLE(現在的Active X)、COM （部件對象模型）和DCOM （分散式部件對象模型）技術。OPC包括一整套介面、屬性和方法的標準集。用於世界上所有主要的自動化控制系統、儀器儀錶及過程式控制制系統的公司。

ServerSuperIO通過載入的設備驅動以網口或串口為通訊鏈路實時與硬體感測器交互、採集數據信息，設備驅動採集到硬體感測器的數據信息之後立即傳遞給OPC Server，OPC Server的數據發生變化後，在OPC Client能夠立即做出響應，這樣更能體現數據的實時性，避免OPC Server定時讀取資料庫的數據信息而造成延遲，也不能及時反應數據變化的真實性。

結構示意如下圖：

運行「ServerSuperIO.Tool.exe」工具，單擊【標籤配置】菜單，把掛載的可運行設備驅動的動態數據介面的屬性映射成Tag標籤。啟動程序後，OPC客戶端就可以實時讀取到數據信息。如下圖：

配置標籤

OPC客戶端讀取數據

與實時資料庫的對接

實時資料庫系統是開發實時控制系統、數據採集系統等的後台支撐軟體。大量使用實時資料庫系統進行控制系統監控，系統先進控制和優化控制，並為企業的生產管理和調度、數據分析、決策支持及遠程在線瀏覽提供實時數據服務和多種數據管理功能。實時資料庫已經成為企業信息化的基礎數據平台，可直接實時採集、獲取企業運行過程中的各種數據，並將其轉化為對各類業務有效的公共信息，滿足企業生產管理、企業過程監控、企業經營管理之間對實時信息完整性、一致性、安全共享的需求，可為企業自動化系統與管理信息系統間建立起信息溝通的橋樑。

實時資料庫的一個重要特性就是實時性，包括數據實時性和事務實時性。數據實時性是現場IO數據的更新周期，不能不考慮數據的實時性。一般數據的實時性主要受現場設備的制約，特別是對於一些比較老的系統而言，情況更是這樣。事務實時性是指資料庫對其事務處理的速度。它可以是事件觸發方式或定時觸發方式。事件觸發是該事件一旦發生可以立刻獲得調度，這類事件可以得到立即處理，但是比較消耗系統資源；定時觸發是在一定時間範圍內獲得調度權。

系統框架示意如下圖：

ServerSuperIO 作為物聯網通訊框架，是系統體系化建設的關鍵節點，同時也需要後台持久化服務的支持。實時採集感測器的點數據，用實時資料庫對採集點數據進行時序存儲是最理想的。

通過持久化介面進行存儲操作，介面示意如下圖：

結構示意如下圖：

此前，科技日報發表文章《離開高檔工業軟體，「中國製造2025」只是夢想》，文章強調：「一硬、一軟、一網、一台是製造業的『新四基』。工業和信息化部副部長懷進鵬如此解釋：『硬』是指自動控制和感知硬體；『軟』是指工業核心軟體；『網』是指工業互聯網；『平台』是指工業雲和智能服務平台。而在新的模式下，軟體成為重要的生產要素；在中國，工業軟體的機會和挑戰並存。2015 年，中國軟體業人均收入 14.1 萬元，僅次於金融行業的 14.2 萬元。軟體從業人員 547 萬人，創造了 4.9 萬億元產值; 但是在所有軟體人員裡面，工業軟體從業人員比例極低;我們大部分大學，變成國外軟體培訓基地，這一點非常悲哀。」

ServerSuperIO 從一開始雛形到現在不斷的迭代、完善，已經有 6 年多的時間。對於軟體從業人員來講，還是要沉下心來。

作者：東方國信子公司北科億力王強