1.自我介紹

            本人已經工作10年，一直在工業領域。在一線幹過實施，下過礦井；幹過專案，帶過團隊；幹過軟體研發，出過產品；幹過專案群管理，售前和市場也接觸過；期間在純軟體公司也幹過將近兩年的時間，熟悉軟體開發流程與管理。雖然沒有取得多大成績，也算經歷豐富了。

           網際網路“行業”如火如荼的發展，曾經也想過轉行去做“網際網路”，奈何猶豫太久，已然提不起太多興趣。憑藉當年的沉澱與積累，有個半成品的框架，在工作索然無味的情況下，毫不猶豫的投身到物聯網框架的開發與產品化的程序中。別人都說物聯網的時代來了，如果真的是這樣，也不知道是自己的選擇好，還是命好。

這方面的工作純屬個人愛好，業餘時間在幹，一般晚上21點到23點是自己的第二個工作時間。這兩年積極的投身到新的框架開發中，提高效能、統一介面、跨平臺……等方面的工作。也做了自己的基礎硬體產品，智慧閘道器。

          有人會問，那你正式工作是幹什麼的？在某集團公司工業版塊負責大資料建設的相關工作。在沒有大資料、雲服務概念的時候，做過遠端E服務相關的專案。說實話，對於傳統行業來講，是很困難的一件事。但是作為企業來講，要麼等死，要麼在改變中死，完全在於自己的選擇。

2.佔領大腦和丟了腳

         不知道從什麼時候，物聯網、大資料、雲端計算……等一批概念流行起來。大廠都在爭奪高制高點，大資料、雲服務、各種標準……，做這些事情都很有意義。但是我在想，大家都去佔領大腦，腳就不重要了嘛？！顯然不是，應該是同等重要。華為某部、中興某儀表……對於基礎物聯層，也是很頭痛的一件事，這是大廈的根基，特別是工業領域。所以，我堅信對於我們的框架有很大的市場應用空間，創造的直接價值那是另外一回事。

3.物聯的現實困難

           對困難理解的前提是對現實世界的認知，有些傳統制造業都不具備物聯的基礎條件，更談不上物聯網、智慧製造、智慧工廠，但是至因為落後，才有廣闊的市場空間。就算有物聯的基礎，條件比較落後，底子比較薄，面臨四個多樣性：裝置多樣性、協議多樣性、通訊機制多樣性、資料多樣性。這就是我們面臨的問題，難道問題有多大嗎？為了生存，企業都說能做。但是結構化的多樣性問題，要用結構化的手段或框架來解決，這是各方面保障的前提。

4.效率與成本

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

5.逆向思維

            大廠都在搞雲平臺、協議標準……，當然他們有資本和實力這樣搞，軟體用他們的、硬體用他們的，對於他們來講，養這麼多人，反而成本是最低的。他們奉行一流企業定標準，用這種思維模式去整合資源，競爭比的就是佔領資源的多少。我們認真考慮一下，對於傳統企業來講，本來生存就很困難，和房地產、網際網路拿投資的沒法比，他們有能力一下子完全統一化的更新換代嘛？！參加上海工業博覽會，也進行了市場調查，簡直是開玩笑。我們再認真考慮一下，用框架性的東西去解決裝置多樣性、協議多樣性、通訊機制多樣性、資料多樣性的問題，在物聯網和整合系統的建設中是否也是整合資源的一種手段？！先解決企業互聯監控的問題，再解決企業標準化的問題，這樣是否也是一種思維模式？！是的，我們就先這樣幹！

        6.發展歷程

          SuperIO&ServerSuperIO最早的雛形於2010年開始開發，當時主要是解決公司內部硬體產品眾多、協議眾多、以前的軟體經常出問題、維護成本高、搞整合系統時各方面都很累。經過兩三年的發展，確實解決了公司內部的產品體系問題，所有硬體產品都可以掛載到平臺下執行。離開公司之後，感覺這個平臺從程式碼、應用等方面還有很大發展空間，2014年逐步產品化後才形成了SuperIO（SIO）這個平臺。

           但是SIO也只是解決了裝置驅動（眾多協議）外掛式掛載的問題，不過只限於執行在Windows系列作業系統下，一般性的PC機和工控機上資料採集完全沒有問題。但是在執行效率方面還有很大提升空間、裝置驅動的介面還可以進一步標準化（為了各層級都可以應用）、跨平臺執行必須攻克、裝置（驅動）之間資訊互動與控制必須實現、框架在不同層級應用的級聯與控制必須實現、多服務例項的應用等等，一系列的框架和技術性問題還可以進一步完善。從整體物聯網建設的框架性方面考慮，從2015年初開始，基於SIO的核心思想重新開發新一代物聯網框架，也就是現在的ServerSuperIO（SSIO）框架，經過兩年多的發展，搭載在智慧閘道器的基礎上，可以形成綜合性的解決方案。

          SSIO通訊框架的設計思想是在SuperIO（SIO）基礎上發展而來，並沒有高大上的技術，主要是工作經驗的積累，適合於不同應用場景的物聯網的資料採集與互動。SSIO和SIO並不是簡單的對IO高效能的操作，而是裝置驅動、IO通道、控制模式和實際硬體裝置之間的協調機制，各方面之間無縫銜接和執行，也是為了解決現實工作和應用場景的一些痛點。

            軟硬體之間的資料互動，並且面臨著複雜的現場環境：

          （1）複雜的、多樣的通訊協議。有標準的協議，例如：Modbus等，也有很多根據標準協議修改的協議格式、以及自定義協議格式，並且千差萬別。對於不好的軟體架構，疲於應對，增加裝置或協議要對整個軟體進行梳理，往往在此過程中出現新的問題或BUG。

         （2）針對不同使用者對軟體介面或功能的要求有很大不同，使之滿足不同使用者的顯示要求，可以自定義資料顯示介面。那麼就需要提供顯示檢視介面，與裝置驅動進行互動。

         （3）既然現場裝置的資料被採集上來，那麼就需要對其進行處理，不僅僅是儲存、查詢、報表等，還有：資料轉發、資料輸出（OPC、模擬量、大屏等）等。那麼就需要提供服務性的介面，與裝置驅動進行互動。

        （4）通訊鏈路的多種性，對於同一個裝置可能要支援RS232/RS485/RS422、RJ45、3G/4G等通訊方式，所以對於一個裝置要對應多種通訊方式（串列埠和網路），也給我們的開發造成很大的障礙。

        （5）裝置驅動、IO通道和實際的現場硬體終端之間鏈路複雜，有可能：一個裝置驅動對應一個IO通道、一個裝置驅動對應多個IO通道、多個裝置驅動對應一個IO通道等情況。

        （6）既然裝置與服務端進行資料互動，那麼就應該對裝置的通訊狀態、IO狀態、以及裝置本身的狀態進行監控，這樣裝置才處於可維護狀態。

        （7）軟體各版本、以及軟體與硬體之間的相容性很差，管理起來錯綜複雜。在框架平臺穩定的情況下，只需要更新裝置驅動。

        為了解決以上諸多問題，開發一個軟體框架，支援二次開發。在不對軟體框架改動的情況下，能夠很方便的接入裝置、維護裝置、整合裝置、處理裝置業務資料等。軟體框架相對穩定，把容易變化的部分進行靈活設計。

          7.框架特點

• 輕型高效能通訊框架，適用於多種應用場，輪詢模式、自控模式、併發模式和單例模式。
• 不光是通訊框架，是裝置驅動、IO通道、控制模式場景的協調機制。
• 支援協議驅動器，可以按規範寫標準協議和自定義協議。
• 支援傳送資料快取器，支援命令快取重發和按優先級別傳送。
• 支援協議過濾器，按規則篩選資料，並且可以承繼介面，自定義過濾方式。
• 支援接收資料快取器，可以快取不符合過濾器的資料，和下次接收資料進行拼接。
• 支援按裝置命令優先級別進行排程裝置，保證有高級別命令的驅動及時傳送。
• 支援一個裝置驅動，同時支援串列埠和網路兩種通訊方式，可以監視IO通道資料。
• 支援一個裝置驅動，在網路通訊時可以支援TCP Server和TCP Client兩種工作模式。
• 支援多裝置共享同一IO通道進行通訊。
• 支援定時清理超時的網路IO通道。
• 支援顯示檢視介面，滿足不同顯示需求。
• 支援服務元件介面，4-20mA輸出、LED大屏顯示、簡訊服務、以及多功能閘道器服務。
• 支援OPC Server服務。
• 支援建立多服務例項，完成不同業務的拆分。
• 支援跨平臺部署，可以執行在Linux和Windows系統。
• 裝置驅動與裝置驅動，裝置驅動與伺服器（雲端）可以實時雙向互動，上傳資料和指令下發。
  

8.一套裝置驅動，支援多種IO通訊

           不管是zigbee、wifi、有線網路，還是RS485、RS232、RS422，總之主要分為兩種硬體介面：網口和串列埠。至於OPC協議，可以用SSIO服務介面的形成間接實現，形成服務外掛的一部分。如果不結構化的設計IO，網口和串列埠獨立存在，隨著產品越來越多，是很頭痛的一件事，也不一定執行穩定。對於ServerSuperIO框架，在此基礎上開發一套裝置驅動可以分別實現通過網口或串列埠與硬體裝置（感測器）進行互動，非常方便。有人認為通訊很簡單，其實如果把眾多問題都考慮進去，那麼將變得很複雜。也有很多純網路通訊框架，業務場景、通訊機制的不同，純網路通訊框架也未必能夠完全的適用於現場環境。根據多年的工作經驗，針對SSIO增加了通訊機制與應用場景，參見：《連載 | 物聯網框架ServerSuperIO教程》1.4種通訊模式機制。

           示意圖如下：

        

9.物聯通訊的級聯

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

           結構示意圖如下：

 

10.裝置之間的通訊、控制

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

             在ServerSuperIO最新的3.1版本中（還沒有釋出），支援裝置向另一個裝置發起傳遞資訊和控制後，被控制裝置是否立即返回確認資訊，還是自主非同步決定返回確認資訊。增加了非同步返回確認資訊的功能，因為控制命令只是發給了另一個裝置驅動，裝置驅動還會進一步與實際的硬體裝置進行互動，與實現硬體互動成功後，再返回確認資訊給發起的源裝置驅動。

           示意圖如下：

 

11.與雲端的互動、控制

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

            示意圖如下：

 

      12.控制模式

         （1）輪詢模式：當串列埠和網路通訊時都可以使用這種控制模式。當有多個裝置連線到通訊平臺時，通訊平臺會輪詢排程裝置進行通訊任務。某一時刻只能有一個裝置傳送請求命令、等待接收返回資料，這個裝置完成傳送、接收（如果遇到超時情況，則自動返回）後，下一個裝置才進行通訊任務，依次輪詢裝置。如下圖：

 

         （2）併發模式：只有網路通訊時可以使用這種控制模式。併發通訊模式是集中傳送所有裝置的請求指令，框架是採用迴圈同步方式傳送請求命令。還有進一步提高的機會，採用並行非同步方式集中傳送請求命令。硬體裝置接收到指令後進行校驗，校驗成功後返回對應指令的資料，通訊平臺非同步監聽到資料資訊後，進行接收操作，然後再進行資料的分發、處理等。如下圖：

 

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

         自控通訊模式可以為二次開發者提供精確的定時請求實時資料機制，使通訊機制更靈活、自主，如果多個裝置驅動使用同一個IO通道的話，時間控制會有偏差。如下圖：

 

         （4）單例模式：只有網路通訊時可以使用這種控制模式。在一個服務例項內只能有一個裝置驅動，相當於一個裝置驅動對應著N多個硬體裝置終端。更適合通訊的資料協議有固定的標準，以命令關鍵字處理不同的資料。適用於高併發的硬體終端裝置主動上傳資料，伺服器端根據資料資訊進行處理和返回相應的資料。如下圖：

 

            13.跨平臺

                   （1）Windows執行效果

 

                   （2）Linux執行效果

物聯網&整合技術(.NET) QQ群：54256083