物聯網建設中通訊互聯層的終極解決方案

標籤：大數   注意   size   爭奪   webapi   協議   新一代   net   http   

1.自我介紹

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

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

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

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

2.佔領大腦和丟了腳

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

3.物聯的現實困難

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

4.效率與成本

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

5.逆向思維

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

5.智能網關，跑Windows 10 IOT和Ubuntu Mate

     網關在物聯網和整合系統建設中是重要的一個環節，實現資料的初步整合（採集），再進行資料的轉寄，形成體系層次清晰的級連網絡系統。市場的網關大至分為兩類：純硬體介面的轉換、搭載作業系統的小型機。當然也有在硬體基礎上搭載自己的軟體架構，但是不多見。在我們的智能網關上可以實現搭載我們ServerSuperIO物聯網架構，使軟體和硬體無縫結合，裝置驅動的介面統一，可以開發一套驅動跑在不同的嵌入式作業系統上，Windows 10 IOT和Ubuntu Mate，對於系統建設的方案選擇更靈活。

     智能網關的硬體設定：

l  四核1.2GHz Broadcom BCM2837 64位CPU。

l  1GB RAM。

l  板載BCM43143 WIFI和藍芽低功能耗（BLE）。

l  40引腳擴充GPIO。

l  4個USB介面。

l  全盡寸HDMI，並且轉VGA介面。

l  微型SD卡連接埠，用於運行作業系統和儲存資料的介質。

l  升級切換的微型USB電源，高達2.5A。

l  可搭載的作業系統：Ubuntu Mate、Windows 10 IOT。

     智能網關實體機照片：

 

6.SuperIO到ServerSuperIO發展曆程和解決的實現問題

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

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

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

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

     如下：

 

8.一套裝置驅動，統一介面，多種平台掛載運行

     針對ServerSuperIO架構的裝置驅動介面進行標準化設計，另外針對ServerSuperIO架構本身進行了跨平台啟動並執行移植工作，所以一次開發裝置驅動，可以在多種平台下掛載運行。現在支援的平台包括：Windows xp SP3以上的版本作業系統（包括Server）、Windows 10 IOT嵌入式作業系統、Ubuntu&Ubuntu Mate作業系統。

     如下：

 

9.物聯通訊的級聯

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

      結構如下：

 

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

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

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

     如下：

 

11.與雲端的互動、控制

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

     如下：

 

12.未來的規劃

     從大環境來講，肯定是有很廣泛的應用；從本公司來講，將來在工業基礎物聯層面，肯定也會用的上；從個人興趣來講，也樂意能夠繼續做這方面的工作，當然是除正式工作之外。

     從ServerSuperIO本身來講，3.1版本（未發布）對代碼進行最佳化以及增加了非同步返回確認資訊的互動能力。後期會增加對資料安全方案的驗證機制，以保障在工業領域應用資料互動與控制的安全性。另外從體繫結構來講，以ServerSuperIO架構為基礎，增加雲端的建設能力，例如：資料分布式持久化等。從嵌入式應用為講，要增加遠程可配置能力等。

13.結束語

     在現在的社會，長期堅持做一件事很不容易，做成產品級以及配合體系方案更不容易。慢慢往下走吧，希望機會會眷顧那些踏實、實乾的人。天道酬勤！！！

 

1.[連載]《C#通訊（串口和網路）架構的設計與實現》

2.[開源]C#跨平台物聯網通訊架構ServerSuperIO（SSIO）介紹

2.應用SuperIO（SIO）和開源跨平台物聯網架構ServerSuperIO（SSIO）構建系統的整體方案

3.C#工業物聯網和整合系統解決方案的技術路線（資料來源、資料擷取、資料上傳與接收、ActiveMQ、Mongodb、WebApi、手機App）

5.ServerSuperIO開源地址：https://github.com/wxzz/ServerSuperIO

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

 

連載教程：

1.4種通訊模式機制
2.服務執行個體的配置參數說明
3.裝置驅動介紹
4.如開發一套裝置驅動，同時支援串口和網路通訊
5.輪詢通訊模式開發及注意事項
6.並發通訊模式開發及注意事項
7.自控通訊模式開發及注意事項
8.單例通訊模式開發及注意事項
9. 協議過濾器，解決一包多發、粘包、冗餘資料
10.持續傳輸大塊資料流的兩種方式（如：檔案）
11.實現裝置（驅動）與裝置（驅動）互動和級聯控制。
12.服務介面的開發，以及與雲端雙向互動
13．自訂視圖顯示介面開發，滿足不同的顯示需求
14．配製工具介紹，以及裝置驅動、視圖驅動、服務執行個體的掛載

 

物聯網建設中通訊互聯層的終極解決方案