概述

不知從何時起，物聯(lián)網(wǎng)、大數(shù)據(jù)、云計算……等一大批概念詞匯流行起來，占領(lǐng)著各大 IT 網(wǎng)站。不能把這三個語匯獨立來看，而是現(xiàn)實系統(tǒng)體系化建設(shè)的三個方面。物聯(lián)網(wǎng)以智能傳感器為基礎(chǔ)的網(wǎng)絡(luò)化建設(shè)，對大量傳感器的實時感知和控制必然會產(chǎn)生大量的數(shù)據(jù)，而對特定行業(yè)的這些數(shù)據(jù)集合進(jìn)行數(shù)學(xué)模型分析必然會產(chǎn)生具有現(xiàn)實的價值。

一個體系三個方面

大公司都在爭奪制高點，大數(shù)據(jù)、云服務(wù)、各種標(biāo)準(zhǔn)……，做這些事情都很有意義。在大家都去占領(lǐng)大腦的時候，難道腳就不重要了嘛？顯然不是，應(yīng)該是同等重要。不少公司對于基礎(chǔ)物聯(lián)網(wǎng)建設(shè)也是很頭痛的一件事，這是系統(tǒng)體系化建設(shè)的根基，特別是工業(yè)領(lǐng)域。所以針對現(xiàn)階段物聯(lián)網(wǎng)建設(shè)中高可用、高擴展性通訊框架的應(yīng)用有很大現(xiàn)實意義和發(fā)展空間。

認(rèn)清物聯(lián)網(wǎng)建設(shè)困難的前提是對現(xiàn)實世界的認(rèn)知，有些特定行業(yè)都根本不具備物聯(lián)的基礎(chǔ)條件，也更談不上物聯(lián)網(wǎng)建設(shè)，相反也證明物聯(lián)網(wǎng)的發(fā)展會有廣闊的市場空間；也有很多具備物聯(lián)網(wǎng)建設(shè)的基礎(chǔ)，但是條件比較落后，底子比較薄，現(xiàn)實面臨四個多樣性的困難：設(shè)備多樣性、協(xié)議多樣性、通訊機制多樣性、數(shù)據(jù)多樣性。這就是我們面臨的問題，但是面對結(jié)構(gòu)化的多樣性問題，要用結(jié)構(gòu)化的手段或框架來解決，這是各方面得到保障的前提。

四個多樣性

大公司都在搞云平臺、協(xié)議標(biāo)準(zhǔn)……，當(dāng)然其有資本和實力，對于他們來說，養(yǎng)這么多人，反而成本是最低的。他們奉行一流企業(yè)定標(biāo)準(zhǔn)，用這種思維模式去整合資源，競爭比的就是占領(lǐng)資源的多少。我們認(rèn)真考慮一下，對于傳統(tǒng)企業(yè)來講，生存本來就很困難，他們有能力在很短的時間內(nèi)完全統(tǒng)一更新?lián)Q代嘛？！參加上海工業(yè)博覽會，也進(jìn)行了市場調(diào)查，這是不現(xiàn)實的。我們再認(rèn)真考慮一下，用框架性的東西去解決設(shè)備多樣性、協(xié)議多樣性、通訊機制多樣性、數(shù)據(jù)多樣性的問題，在物聯(lián)網(wǎng)和集成系統(tǒng)的建設(shè)中是否也是整合資源的一種手段？先解決企業(yè)互聯(lián)監(jiān)控的問題，再解決企業(yè)標(biāo)準(zhǔn)化的問題，這樣是否也是一種思維模式？是的，我們就先這樣干！

不同方式的整合資源

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

降本增效

ServerSuperIO就是以這樣的一種思維方式演變而來，ServerSuperIO不僅僅是通訊框架，否則它和任何其他的通訊框架沒有任何區(qū)別，也不具備現(xiàn)實意義。ServerSuperIO是一個物聯(lián)網(wǎng)框架，首先是以設(shè)備（傳感器）為核心構(gòu)建的框架，設(shè)備（傳感器）的協(xié)議無關(guān)性，可以隨意掛載設(shè)備驅(qū)動在框架下運行。所以ServerSuperIO本質(zhì)上協(xié)調(diào)設(shè)備驅(qū)動（協(xié)議）、IO通道（COM和NET）、運行機制（模式）之間的協(xié)調(diào)機制，使之無縫結(jié)合、運行。框架具備如下特點：

• 輕型高性能通信框架，適用多種應(yīng)用場：輪詢模式、自控模式、并發(fā)模式和單例模式。

• 支持協(xié)議驅(qū)動器，可以按規(guī)范寫標(biāo)準(zhǔn)協(xié)議和自定義協(xié)議。

• 支持發(fā)送數(shù)據(jù)緩存器，支持命令緩存重發(fā)和按優(yōu)先級別發(fā)送。

• 支持協(xié)議過濾器，按規(guī)則篩選數(shù)據(jù)，并且可以承繼接口，自定義過濾方式。

• 支持接收數(shù)據(jù)緩存器，可以緩存不符合過濾器的數(shù)據(jù)，和下次接收數(shù)據(jù)進(jìn)行拼接。

• 支持按設(shè)備命令優(yōu)先級別進(jìn)行調(diào)度設(shè)備，保證有高級別命令的驅(qū)動及時發(fā)送。

• 支持一個設(shè)備驅(qū)動，同時支持串口和網(wǎng)絡(luò)兩種通訊方式，可以監(jiān)視IO通道數(shù)據(jù)。

• 支持一個設(shè)備驅(qū)動，在網(wǎng)絡(luò)通訊時可以支持TCP Server和TCP Client兩種工作模式。

• 支持多設(shè)備共享同一IO通道進(jìn)行通訊。

• 支持定時清理超時的網(wǎng)絡(luò)IO通道。

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

• 支持服務(wù)組件接口，例如：4-20mA輸出、LED大屏顯示、短信服務(wù)、以及多功能網(wǎng)關(guān)服務(wù)。

• 設(shè)備驅(qū)動與設(shè)備驅(qū)動，設(shè)備驅(qū)動與服務(wù)器（云端）可以實時雙向交互，上傳數(shù)據(jù)和指令下發(fā)。

• 支持OPC Server服務(wù)。

• 支持創(chuàng)建多服務(wù)實例，完成不同業(yè)務(wù)的拆分。

• 支持跨平臺部署，可以運行在Linux和Windows系統(tǒng)。

通訊機制

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

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

主動請求方式又可以稱之為呼叫應(yīng)答方式或主從方式。也就是說，主動權(quán)在軟件框架端，只有軟件框架主動發(fā)送請求命令，從機（硬件設(shè)備、傳感器等）接收到命令后并且檢驗數(shù)據(jù)的完整性，以及確定是否發(fā)給自己的命令，校驗成功后，返回指定的數(shù)據(jù)信息，完成一次完整的鏈路通訊過程。呼叫應(yīng)答通訊方式，如圖5所示：

呼叫應(yīng)答通訊方式

被動接收方式是軟件框架實時監(jiān)測IO通道，只要有數(shù)據(jù)信息就會提取出來，進(jìn)行數(shù)據(jù)校驗，檢驗成功后，分析、處理、保存數(shù)據(jù)信息。例如設(shè)備、傳感器等定時發(fā)送狀態(tài)數(shù)據(jù)。這種通訊方式，如下圖：

被動接收方式

在復(fù)雜的應(yīng)用場景中，這兩種通訊方式都有可能存在，此類情況一般是采用以太網(wǎng)鏈路進(jìn)行通訊。針對只有外接串口的設(shè)備可以通過以太網(wǎng)轉(zhuǎn)換模塊來接入。

輪詢通訊機制

這是框架最早的運行模式，串口和網(wǎng)絡(luò)通訊時都可以使用這種控制模式。當(dāng)有多個設(shè)備 連接到通訊平臺時，通訊平臺會輪詢調(diào)度設(shè)備進(jìn)行通訊任務(wù)。某一時刻只能有一個設(shè)備發(fā)送請求命令、等待接收返回數(shù)據(jù)，這個設(shè)備完成發(fā)送、接收（如果遇到超時 情況，則自動返回）后，下一個設(shè)備才進(jìn)行通訊任務(wù)，依次輪詢設(shè)備。

應(yīng)用場景是這樣的，服務(wù)端與設(shè)備進(jìn)行通訊遵循呼叫應(yīng)答的方式，也就是IO可用的情況下，服務(wù)端先發(fā)起通訊命令請求，設(shè)備根據(jù)命令信息，檢驗通過后返回數(shù)據(jù)給服務(wù)端。這種通訊模式很好理解，每個設(shè)備的通訊都遵循排隊的原則。但是如果某個設(shè)備的命令需要及時發(fā)送，怎么辦？ServerSuperIO框架是支持設(shè)備優(yōu)先級別調(diào)度的，例如：對某個設(shè)備要進(jìn)行實時的檢測，需要連續(xù)發(fā)送命令，那么就需要對設(shè)備進(jìn)行高級別設(shè)置，發(fā)送請求數(shù)據(jù)命令。

通訊結(jié)構(gòu)如下圖：

并發(fā)通訊機制

網(wǎng)絡(luò)通訊的情況下，輪詢模式顯然效率比較低，那么可以采用并發(fā)模式。并發(fā)通訊模式是集中發(fā)送給所有設(shè)備請求指令，框架是采用循環(huán)同步方式發(fā)送請求命令給每個IO通道對應(yīng)的設(shè)備，當(dāng)然也可以采用并行異步方式集中發(fā)送請求命令。硬件設(shè)備接收到指令后進(jìn)行校驗，校驗成功后返回對應(yīng)指令的數(shù)據(jù)，通訊平臺異步監(jiān)聽到數(shù)據(jù)信息后，進(jìn)行接收操作，然后再進(jìn)行數(shù)據(jù)的分發(fā)、處理等。

那么這里就涉及到IO通道接收到的數(shù)據(jù)是異步接收的，如何才能和設(shè)備驅(qū)動匹配上（把數(shù)據(jù)分發(fā)到設(shè)備驅(qū)動上），這是能過DeviceCode和DeviceIP兩種方式來實現(xiàn)的。DeviceCode可以是設(shè)備地址或是設(shè)備編碼，DeviceIP是預(yù)先設(shè)置好的參數(shù)，要求終端設(shè)備的IP地址是固定的。

通訊結(jié)構(gòu)如下圖：

自控通訊機制

只有網(wǎng)絡(luò)通訊時可以使用這種控制模式。自控通訊模式與并發(fā)通訊模式類似，區(qū)別在于發(fā)送指令操作交給設(shè)備驅(qū)動本身進(jìn)行控制，或者說交給二次開發(fā)者，二次開發(fā)者可以通過時鐘定時用事件驅(qū)動的方式發(fā)送指令數(shù)據(jù)。硬件設(shè) 備接收到指令后進(jìn)行校驗，校驗成功后返回對應(yīng)指令的數(shù)據(jù)，通訊平臺異步監(jiān)聽到數(shù)據(jù)信息后，進(jìn)行接收操作，然后再進(jìn)行數(shù)據(jù)的分發(fā)、處理等。

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

同樣涉及到數(shù)據(jù)的分發(fā)，和并發(fā)模式一樣。

通訊結(jié)構(gòu)如下圖：

單例通訊機制

只有網(wǎng)絡(luò)通訊時可以使用這種控制模式。在一個服務(wù)實例內(nèi)只能有一個設(shè)備驅(qū)動，相當(dāng)于一個設(shè)備驅(qū)動對應(yīng)著N多個硬件設(shè)備終端。更適合通訊的數(shù)據(jù)協(xié)議有固定的標(biāo)準(zhǔn)，以命令關(guān)鍵字處理不同的數(shù)據(jù)。適用于高并發(fā)的硬件終端設(shè)備主動上傳數(shù)據(jù)，服務(wù)器端根據(jù)數(shù)據(jù)信息進(jìn)行處理和返回相應(yīng)的數(shù)據(jù)。 通訊結(jié)構(gòu)如下圖：

“傳感器”驅(qū)動的插件化應(yīng)用

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

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

• 可以在無需對程序進(jìn)行重新編譯和發(fā)布的條件下擴展程序的功能。

• 可以在不需要程序源代碼的環(huán)境下為程序增加新的功能。

• 在一個程序的業(yè)務(wù)邏輯不斷發(fā)生改變、新的規(guī)則頻頻加入時能夠靈活適應(yīng)。

實現(xiàn)插件機制一般有3種技術(shù)：基于動態(tài)連接庫DLL的插件、基于組件對象模型COM的插件、以及基于.NET反射技術(shù)的插件。ServerSuperIO是使用.NET反射技術(shù)實現(xiàn)的插件機制。

插件式框架的宿主程序啟動后，它首先會加載相應(yīng)的配置文件（例如：設(shè)備驅(qū)動配置文件等），找到相應(yīng)的插件程序集，這些程序集以DLL文件格式存在，框架的宿主程序會找到指定的插件類型，由插件引擎依據(jù)插件類型（例如：IRunDevice）生成對象實例，由框架的宿主程序的管理器對插件實例進(jìn)行管理和調(diào)度。

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

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

在具有多個邏輯層次的結(jié)構(gòu)設(shè)計中，各層之間的通信大多通過接口來實現(xiàn)，接口不會輕易改變，如果一個層的功能發(fā)生變化，不會影響其他層；只要正常實現(xiàn)了接口的組件功能，那么程序的運行就沒有問題。這種做法使得各層之間的相互影響降低到最低，總之，接口在多業(yè)務(wù)層級中能夠更好的解耦，所以每個設(shè)備驅(qū)動都可以有自己的業(yè)務(wù)邏輯。

可掛載的設(shè)備驅(qū)動信息在配置文件中進(jìn)行標(biāo)注，當(dāng)掛載新的設(shè)備驅(qū)動的時候，如增加設(shè)備，就會從這個配置組中加載信息，以便操作人員進(jìn)行選擇。設(shè)備驅(qū)動配置信息定義如下圖：

當(dāng)調(diào)用增加設(shè)備驅(qū)動窗體的時候會從配置文件讀取程序集信息，以完成增加設(shè)備驅(qū)動，并且在ServerSuperIO框架下運行。

一套驅(qū)動同時支持多種IO鏈路

作為物聯(lián)網(wǎng)通訊框架平臺軟件，IO是核心部分之一，涉及到與硬件設(shè)備、軟件之間的信息數(shù)據(jù)交互，主要包括兩部分：IO實例與IO管理器。IO實例負(fù)責(zé)直接對串口和網(wǎng)絡(luò)進(jìn)行操作；IO管理器負(fù)責(zé)對IO實例進(jìn)行管理。

框架平臺一大特點就是開發(fā)一套設(shè)備驅(qū)動（插件）同時支持串口和網(wǎng)絡(luò)兩種通訊方式，而兩種通訊方式的切換只需要改動配制文件。

不同的設(shè)備類型和協(xié)議、不同的通訊方式，用堆代碼的方式進(jìn)行開發(fā)，根本無法適應(yīng)不同場景的應(yīng)用，提高了代碼的維護(hù)成本，以及修改代碼可能造成潛在的BUG，是讓人很頭疼的一件事。

在開始設(shè)計框架平臺的時候，一個核心的思想就是把變的東西要設(shè)計靈活，把不變的東西設(shè)計穩(wěn)定。對于設(shè)備的協(xié)議就是變的東西，對于IO部分就是相對不變的東西，那就需要對串口IO和網(wǎng)絡(luò)IO進(jìn)行整合。不僅在代碼層面要運行穩(wěn)定；在邏輯層面，不管是串口IO還是網(wǎng)絡(luò)IO在框架內(nèi)部是統(tǒng)一的接口，所有對IO的操作都會通過這個統(tǒng)一的接口來完成。

示意如下圖：

數(shù)據(jù)過濾器，解決一包多發(fā)、粘包、冗余數(shù)據(jù)

（1）一包多發(fā)及解決

多包發(fā)送數(shù)據(jù)是應(yīng)用環(huán)境中的一種情況或一個問題，并不是我們會這樣實際應(yīng)用，而是說在接收過程中多次接收數(shù)據(jù)才能完整接收客戶端一次發(fā)送的數(shù)據(jù)，可能由于網(wǎng)絡(luò)環(huán)境或發(fā)送數(shù)據(jù)端造成的，示意如下圖：

例如實時數(shù)據(jù)的完整包為：55 AA 00 61 43 7A 00 00 43 B4 15 0D。那么接收數(shù)據(jù)的時候，第一次接收到：55 AA 00 61 43 7A 00 00 43 B4 15，第二次接到：0D。按通訊協(xié)議應(yīng)該能夠把這兩次接收的數(shù)據(jù)進(jìn)行自動拼接，形成完整的數(shù)據(jù)并進(jìn)行解析2。

（2）粘包及解決

在通訊領(lǐng)域中是經(jīng)常會遇到的問題。也就是多包數(shù)據(jù)一次性的接收，那么就要合理的進(jìn)行拆包。還有一種情況，就是多包半的數(shù)據(jù)一次性的接收，那半包的數(shù)據(jù)結(jié)合“1.一包多發(fā)及解決”來解決這個問題，示意如下圖：

（3）冗余數(shù)據(jù)的出現(xiàn)及解決

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

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

• FixedEndReceiveFliter：固定結(jié)尾的協(xié)議過濾器。

• FixedHeadAndEndReceiveFliter：固定開頭和結(jié)尾的協(xié)議過濾器。

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

• FixedHeadReceiveFliter：固定開頭的協(xié)議過濾器。

• FixedLengthReceiveFliter：固定長度的協(xié)議過濾器。

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

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

物聯(lián)網(wǎng)建設(shè)中數(shù)據(jù)采集是基礎(chǔ)，進(jìn)行控制是目的，這是兩個根本要素。在采集設(shè)備數(shù)據(jù)的時候，如果該設(shè)備的實時數(shù)據(jù)出現(xiàn)異常，那么是否存在其他設(shè)備要進(jìn)行聯(lián)動？也就是說一個設(shè)備出現(xiàn)異常之后，要對其他某個設(shè)備進(jìn)行聯(lián)動控制，以達(dá)到避免出現(xiàn)更大危險的情況。

那么不僅要對某個設(shè)備進(jìn)行聯(lián)動控制，還要對控制的結(jié)果進(jìn)行反饋給出現(xiàn)異常的設(shè)備。形成異常、聯(lián)動、控制、反饋的閉環(huán)，以達(dá)到監(jiān)測與控制共同作用的目的。

如果單單是采集硬件的數(shù)據(jù)與控制，也只能算是本地的系統(tǒng)，但是在物聯(lián)網(wǎng)和集成系統(tǒng)建設(shè)中，必須形成體系化、網(wǎng)絡(luò)化框架。所以ServerSuperIO在采集本范圍內(nèi)的數(shù)據(jù)信息與控制外，還要形成與上一級的ServerSuperIO進(jìn)行數(shù)據(jù)交互，以及接收下一級的ServerSuperIO的交互數(shù)據(jù)，那么ServerSuperIO之間就形成了級聯(lián)的關(guān)系，主要完成兩大職責(zé)：數(shù)據(jù)的級聯(lián)上傳和反向控制，進(jìn)而對設(shè)備本身進(jìn)行級聯(lián)控制。

結(jié)構(gòu)示意圖如下：

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

采集與控制單個設(shè)備，在實際應(yīng)用中還遠(yuǎn)遠(yuǎn)不夠，還要能夠設(shè)備與設(shè)備之間進(jìn)行信息傳遞與控制，并且返回給發(fā)送控制源設(shè)備確認(rèn)信息。例如：在監(jiān)測流量計嚴(yán)重報警的情況下，是否應(yīng)該調(diào)節(jié)或控制液體源頭的閥門。類似的例子很多。

ServerSuperIO支持設(shè)備向另一個設(shè)備發(fā)起傳遞信息和控制后，被控制設(shè)備是否立即返回確認(rèn)信息，還是自主異步?jīng)Q定返回確認(rèn)信息。增加了異步返回確認(rèn)信息的功能，因為控制命令只是發(fā)給了另一個設(shè)備驅(qū)動，設(shè)備驅(qū)動還會進(jìn)一步與實際的硬件設(shè)備進(jìn)行交互，與實現(xiàn)硬件交互成功后，再返回確認(rèn)信息給發(fā)起的源設(shè)備驅(qū)動。

示意圖如下：

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

ServerSuperIO提供了服務(wù)驅(qū)動的接口，一些除設(shè)備驅(qū)動類的功能以外，都可以以服務(wù)驅(qū)動的方式存在，例如：多設(shè)備采集的數(shù)據(jù)的融合模型計算、與其他平臺或上層進(jìn)行交互等等，在此僅以與服務(wù)端進(jìn)行交互為實例進(jìn)行介紹。與設(shè)備驅(qū)動之間的交互與控制不同的是，設(shè)備驅(qū)動主動把采集的數(shù)據(jù)信息傳遞給服務(wù)驅(qū)動，服務(wù)驅(qū)動與云端進(jìn)行交互，在接收云端指令后，發(fā)起傳遞信息或控制設(shè)備驅(qū)動，設(shè)備驅(qū)動再返回確認(rèn)信息給服務(wù)驅(qū)動。

示意圖如下：

與OPC Server的對接

OPC(OLE for Process Control, 用于過程控制的OLE)是一個工業(yè)標(biāo)準(zhǔn)，基于微軟的OLE(現(xiàn)在的Active X)、COM （部件對象模型）和DCOM （分布式部件對象模型）技術(shù)。OPC包括一整套接口、屬性和方法的標(biāo)準(zhǔn)集。用于世界上所有主要的自動化控制系統(tǒng)、儀器儀表及過程控制系統(tǒng)的公司。

ServerSuperIO通過加載的設(shè)備驅(qū)動以網(wǎng)口或串口為通訊鏈路實時與硬件傳感器交互、采集數(shù)據(jù)信息，設(shè)備驅(qū)動采集到硬件傳感器的數(shù)據(jù)信息之后立即傳遞給OPC Server，OPC Server的數(shù)據(jù)發(fā)生變化后，在OPC Client能夠立即做出響應(yīng)，這樣更能體現(xiàn)數(shù)據(jù)的實時性，避免OPC Server定時讀取數(shù)據(jù)庫的數(shù)據(jù)信息而造成延遲，也不能及時反應(yīng)數(shù)據(jù)變化的真實性。

結(jié)構(gòu)示意如下圖：

運行“ServerSuperIO.Tool.exe”工具，單擊【標(biāo)簽配置】菜單，把掛載的可運行設(shè)備驅(qū)動的動態(tài)數(shù)據(jù)接口的屬性映射成Tag標(biāo)簽。啟動程序后，OPC客戶端就可以實時讀取到數(shù)據(jù)信息。如下圖：

配置標(biāo)簽

OPC客戶端讀取數(shù)據(jù)

與實時數(shù)據(jù)庫的對接

實時數(shù)據(jù)庫系統(tǒng)是開發(fā)實時控制系統(tǒng)、數(shù)據(jù)采集系統(tǒng)等的后臺支撐軟件。大量使用實時數(shù)據(jù)庫系統(tǒng)進(jìn)行控制系統(tǒng)監(jiān)控，系統(tǒng)先進(jìn)控制和優(yōu)化控制，并為企業(yè)的生產(chǎn)管理和調(diào)度、數(shù)據(jù)分析、決策支持及遠(yuǎn)程在線瀏覽提供實時數(shù)據(jù)服務(wù)和多種數(shù)據(jù)管理功能。實時數(shù)據(jù)庫已經(jīng)成為企業(yè)信息化的基礎(chǔ)數(shù)據(jù)平臺，可直接實時采集、獲取企業(yè)運行過程中的各種數(shù)據(jù)，并將其轉(zhuǎn)化為對各類業(yè)務(wù)有效的公共信息，滿足企業(yè)生產(chǎn)管理、企業(yè)過程監(jiān)控、企業(yè)經(jīng)營管理之間對實時信息完整性、一致性、安全共享的需求，可為企業(yè)自動化系統(tǒng)與管理信息系統(tǒng)間建立起信息溝通的橋梁。

實時數(shù)據(jù)庫的一個重要特性就是實時性，包括數(shù)據(jù)實時性和事務(wù)實時性。數(shù)據(jù)實時性是現(xiàn)場IO數(shù)據(jù)的更新周期，不能不考慮數(shù)據(jù)的實時性。一般數(shù)據(jù)的實時性主要受現(xiàn)場設(shè)備的制約，特別是對于一些比較老的系統(tǒng)而言，情況更是這樣。事務(wù)實時性是指數(shù)據(jù)庫對其事務(wù)處理的速度。它可以是事件觸發(fā)方式或定時觸發(fā)方式。事件觸發(fā)是該事件一旦發(fā)生可以立刻獲得調(diào)度，這類事件可以得到立即處理，但是比較消耗系統(tǒng)資源；定時觸發(fā)是在一定時間范圍內(nèi)獲得調(diào)度權(quán)。

系統(tǒng)框架示意如下圖：

ServerSuperIO 作為物聯(lián)網(wǎng)通訊框架，是系統(tǒng)體系化建設(shè)的關(guān)鍵節(jié)點，同時也需要后臺持久化服務(wù)的支持。實時采集傳感器的點數(shù)據(jù)，用實時數(shù)據(jù)庫對采集點數(shù)據(jù)進(jìn)行時序存儲是最理想的。

通過持久化接口進(jìn)行存儲操作，接口示意如下圖：

結(jié)構(gòu)示意如下圖：

結(jié)束語

最近科技日報發(fā)表文章《離開高檔工業(yè)軟件，“中國制造2025”只是夢想》，文章強調(diào)：“一硬、一軟、一網(wǎng)、一臺是制造業(yè)的‘新四基’。工業(yè)和信息化部副部長懷進(jìn)鵬如此解釋：‘硬’是指自動控制和感知硬件；’軟’是指工業(yè)核心軟件；‘網(wǎng)’是指工業(yè)互聯(lián)網(wǎng)；‘平臺’是指工業(yè)云和智能服務(wù)平臺。而在新的模式下，軟件成為重要的生產(chǎn)要素；在中國，工業(yè)軟件的機會和挑戰(zhàn)并存。2015 年，中國軟件業(yè)人均收入 14.1 萬元，僅次于金融行業(yè)的 14.2 萬元。軟件從業(yè)人員 547 萬人，創(chuàng)造了 4.9 萬億元產(chǎn)值; 但是在所有軟件人員里面，工業(yè)軟件從業(yè)人員比例極低；我們大部分大學(xué)，變成國外軟件培訓(xùn)基地，這一點非常悲哀。”

ServerSuperIO 從一開始雛形到現(xiàn)在不斷的迭代、完善，已經(jīng)有 6 年多的時間。對于軟件從業(yè)人員來講，還是要沉下心來。