作者：王強，有10年工業領域開發和管理經驗，在煤炭行業、電力行業、環保和節能行業、冶金行業等多家工業和IT企業從事過開發技術與管理工作；對物聯網和系統集成系統産品有豐富理論知識和行業背景經驗；開發工作一直使用C#為主，現在從事工業領域大數據平台的建設工作。

概述

不知從何時起，物聯網、大數據、雲計算……等一大批概念詞彙流行起來，占領着各大 IT 網站。不能把這三個語彙獨立來看，而是現實系統體系化建設的三個方面。物聯網以智能傳感器為基礎的網絡化建設，對大量傳感器的實時感知和控制必然會産生大量的數據，而對特定行業的這些數據集合進行數學模型分析必然會産生具有現實的價值。

一個體系三個方面

大公司都在争奪制高點，大數據、雲服務、各種标準……，做這些事情都很有意義。在大家都去占領大腦的時候，難道腳就不重要了嘛？顯然不是，應該是同等重要。不少公司對于基礎物聯網建設也是很頭痛的一件事，這是系統體系化建設的根基，特别是工業領域。所以針對現階段物聯網建設中高可用、高擴展性通訊框架的應用有很大現實意義和發展空間。

認清物聯網建設困難的前提是對現實世界的認知，有些特定行業都根本不具備物聯的基礎條件，也更談不上物聯網建設，相反也證明物聯網的發展會有廣闊的市場空間；也有很多具備物聯網建設的基礎，但是條件比較落後，底子比較薄，現實面臨四個多樣性的困難：設備多樣性、協議多樣性、通訊機制多樣性、數據多樣性。這就是我們面臨的問題，但是面對結構化的多樣性問題，要用結構化的手段或框架來解決，這是各方面得到保障的前提。

四個多樣性

大公司都在搞雲平台、協議标準……，當然其有資本和實力，對于他們來說，養這麼多人，反而成本是最低的。他們奉行一流企業定标準，用這種思維模式去整合資源，競争比的就是占領資源的多少。我們認真考慮一下，對于傳統企業來講，生存本來就很困難，他們有能力在很短的時間内完全統一更新換代嘛？！參加上海工業博覽會，也進行了市場調查，這是不現實的。我們再認真考慮一下，用框架性的東西去解決設備多樣性、協議多樣性、通訊機制多樣性、數據多樣性的問題，在物聯網和集成系統的建設中是否也是整合資源的一種手段？先解決企業互聯監控的問題，再解決企業标準化的問題，這樣是否也是一種思維模式？是的，我們就先這樣幹！

不同方式的整合資源

曾接觸過上海一家公司，有專人負責網關層的數據采集，有專人負責服務（雲）端的對接，不太穩定、經常出現問題。解決細節問題，不能用細節的思維方式去解決，而是要有更廣闊的思維、結構化思路才能夠徹底的、更好的解決問題。網關層、服務端是否可以使用同一套框架？并且框架之間是否可以無縫對接？如果可以實現，應用同一套框架，開發效率會提高，用人成本和時間成本會降低。好的組織結構、好的框架要解決效率和成本的問題，否則沒有任何價值。

降本增效

ServerSuperIO就是以這樣的一種思維方式演變而來，ServerSuperIO不僅僅是通訊框架，否則它和任何其他的通訊框架沒有任何區别，也不具備現實意義。ServerSuperIO是一個物聯網框架，首先是以設備（傳感器）為核心構建的框架，設備（傳感器）的協議無關性，可以随意挂載設備驅動在框架下運行。所以ServerSuperIO本質上協調設備驅動（協議）、IO通道（COM和NET）、運行機制（模式）之間的協調機制，使之無縫結合、運行。框架具備如下特點：

• 輕型高性能通信框架，适用多種應用場：輪詢模式、自控模式、并發模式和單例模式。

• 支持協議驅動器，可以按規範寫标準協議和自定義協議。

• 支持發送數據緩存器，支持命令緩存重發和按優先級别發送。

• 支持協議過濾器，按規則篩選數據，并且可以承繼接口，自定義過濾方式。

• 支持接收數據緩存器，可以緩存不符合過濾器的數據，和下次接收數據進行拼接。

• 支持按設備命令優先級别進行調度設備，保證有高級别命令的驅動及時發送。

• 支持一個設備驅動，同時支持串口和網絡兩種通訊方式，可以監視IO通道數據。

• 支持一個設備驅動，在網絡通訊時可以支持TCP Server和TCP Client兩種工作模式。

• 支持多設備共享同一IO通道進行通訊。

• 支持定時清理超時的網絡IO通道。

• 支持顯示視圖接口，滿足不同人機對話的需求。

• 支持服務組件接口，例如：4-20mA輸出、LED大屏顯示、短信服務、以及多功能網關服務。

• 設備驅動與設備驅動，設備驅動與服務器（雲端）可以實時雙向交互，上傳數據和指令下發。

• 支持OPC Server服務。

• 支持創建多服務實例，完成不同業務的拆分。

• 支持跨平台部署，可以運行在Linux和Windows系統。

通訊機制

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

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

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

呼叫應答通訊方式

被動接收方式是軟件框架實時監測IO通道，隻要有數據信息就會提取出來，進行數據校驗，檢驗成功後，分析、處理、保存數據信息。例如設備、傳感器等定時發送狀态數據。這種通訊方式，如下圖：

被動接收方式

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

輪詢通訊機制

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

應用場景是這樣的，服務端與設備進行通訊遵循呼叫應答的方式，也就是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的操作都會通過這個統一的接口來完成。

示意如下圖：

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

（1）一包多發及解決

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

例如實時數據的完整包為：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。

（2）粘包及解決

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

（3）冗餘數據的出現及解決

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

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

• FixedEndReceiveFliter：固定結尾的協議過濾器。

• FixedHeadAndEndReceiveFliter：固定開頭和結尾的協議過濾器。

• FixedHeadAndLengthReceiveFliter：固定開頭和長度的協議過濾器。

• FixedHeadReceiveFliter：固定開頭的協議過濾器。

• FixedLengthReceiveFliter：固定長度的協議過濾器。

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

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

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

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

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

結構示意圖如下：

（1）傳感器之間的交互、控制

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

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

示意圖如下：

（2）傳感器與雲端的交互、控制

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 年多的時間。對于軟件從業人員來講，還是要沉下心來。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部