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

時間 2019-11-07

標籤聯網建設中通信互聯終極解決方案简体版

原文原文鏈接

1.自我介紹html

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

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

這方面的工做純屬我的愛好，業餘時間在幹，通常晚上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、有線網絡，仍是RS48五、RS23二、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框架爲基礎，增長雲端的建設能力，例如：數據分佈式持久化等。從嵌入式應用爲講，要增長遠程可配置能力等。