cookieOptions = {...}; .物聯網設備 Gateway 系統架構設計 - 3S Market「全球智慧科技應用」市場資訊網

智慧生活設計事務所


2019年9月16日 星期一

What is an IoT Gateway?


任何顏色車牌——都拍攝的清清楚楚!

來源:文刀 技术汇(jishuhui_2015)


1、背景介紹
隨著業務的不斷擴大,有一批設備需要對接到我們的平台裡,所以我嘗試著去設計一下,我們公司的設備 Gateway 系統架構。

目前接入的均為無線設備,設備與載體可隨時移動,使用普通 SIM 卡流量,所以沒有固定 IP 地址。至於設備網關1.0 的核心功能,說來也簡單,攏共分為三大部分:

① 設備安裝/綁定。

② 設備數據即時上報

③ 設備運維


1 設備網關核心功能


2、四層結構
讓我們從另一個視角來看待設備 Gateway :層次結構。

我整理了一下整個業務過程,追蹤了一遍整個數據流向,於是乎很容易就得出了,如下的四層結構圖:



設備網關四層結構


整個層次結構自底向上依次為數據層、控制層、應用層、表現(顯示)層,該層次結構也成為了我之後設計系統架構的指導思想。

現在對每個層次做一個簡單的介紹:
數據層。處於底層,整個系統的數據源頭,很明顯是一個最基礎的層次。

控制層。這是一個承上啓下的關鍵層次,最主要的功能是指令的解析,以及指令的收發。

應用層。亦可稱之為業務層,這個層次與系統的業務邏輯是緊密相關的,一些業務的實現都將在這裡得以發揮。對上承接的是顯示層,進而可以透過控制層,對設備進行指令的收發,對下接入的是控制層,可以獲取設備相關數據提交給顯示層。

顯示層。亦可稱之為交互層,是人機交互,數據可視化的切入點。不難看出,這個層次是直接與人打交道的,所以在滿足業務需求的同時,需要設計得足夠人性化才行。

透過上述的介紹,結合層次結構圖,不難得出:數據層和控制層是業務無關的,我們可以統稱為「協議層」,而應用層和顯示層是業務相關的,我們可以統稱為「系統層」。整個層次結構相互獨立,而又彼此相連,達到了弱耦合的目的。

3、架構演進(level-1)
做出整個架構也是一個很痛苦的過程,唯恐有考慮不周的地方,導致今後會不斷踩坑。也非常感謝在這個過程中,給我提供幫助和建議的業內人士,在他們的指點下,我才有了更多的靈感。

至於所謂的 IoT 體系結構,也並沒有完全遵循。整個業務場景,也不像是一個非常標準的物聯網,所以給自己的要求不是很高,設計出來的架構堪用就行。

首先,我們從一個較高的視角去看待,整個架構是這樣子的:


3 設備網關係統架構(level-1)


從圖中不難看出,整個設備 Gateway 存在四個關鍵角色。
設備以及設備組成的群組(Device Group),是最基礎的角色,屬於數據層。考慮到今後可能會對設備做精細化管理,所以會按一定的規則(比如地域,組織)對設備進行分組,這部分設計在前期體現得不是很明顯。

中控平台(Center Controller),對應的是控制層。這個角色的主要工作有數據採集,設備指令的收發等,值得注意的是,接入到系統裡面的設備廠商可能不止一家,設備種類也是形形色色,報文協議也不盡相同,因此中控平台應該被設計成「對設備類型不敏感」的,以便提升中控平台的相容性,可擴展性,以及可用性。(如是以資安角度考量,相容性與可拓展性是要有所取捨的!)

業務處理器(Biz Processor),對應的是應用層(業務層)。這個角色集中體現了系統的業務需求,包括設備維運監控,數據分析以及持久化,日誌分析,當然,這也是建立在中控平台的基礎之上。

設備管理系統(Management System),對應的是顯示層。這個角色是直接針對終端用戶的,是一個可操作的人機交互平台,該平台可以透過業務處理器,控制整個數據鏈條。因為是整個架構的最高層級,透過對底層數據的有效整合,想相空間還是很大的。

以上就是設備 Gateway 架構的 Level-1,緊接著我們再更深入的剖析整個架構,進入 Level-2。

4、架構演進(level-2)
這部分內容,我們深入到四個角色的內部,窺探其中的結構組成。

1) 設備以及設備群組。這裡我們將引入一個叫作「子設備」的概念,即一個設備對象下,會再附屬若干個設備,我們稱之為「子設備」。當然,一個設備也可能沒有子設備,依實際情況而定。

舉個例子: 以一扇門作為一個設備,那麼密碼鎖,鎖舌,紅外探頭都可以是子設備再比如地震監測的探針,就是一個獨立的設備,下屬沒有子設備。



4 「子設備」概念


這樣設計的目的,是為了能夠更精細化地對接入的設備進行控制,進可控制單個子設備,退可控制整個大設備。此外,對於平台內的所有大小設備,都不會直接相互進行通信,都是直接與中控平台打交道的。

2) 中控平台。我把這個角色定位為一種中間件,如下是中控平台的組件圖:


5 中控平台組件圖


整個中控平台由八大組件構成,下面做一個簡單的介紹。

連接器(Connector)。這個組件是控制層與數據層的數據傳輸管道,維護著中控平台和各個設備的數據連接,數據傳輸連接都是基於 TCP/IP 協議。

REST API中控平台作為協議層與系統層的樞紐,對下層提供了連接器,對上層則提供了 RESTful 接口。因為設備 Gateway 將會使用微服務架構風格,所以使用的是 REST API,暫不考慮其他的遠端調用方式。

訊息佇列或稱消息隊列,Message Queue)服務。主要是解決應用耦合,異步消息,流量削鋒等問題,最終實現高性能,高可用,可伸縮和最終一致性架構,有利於實現協議層與系統層準即時通信。

協議解析引擎(Protocol Parser)。這個組件很好理解,因為要適配不同的源設備,不同的設備廠商,協議規範是不一樣的,需要透過協議解析引擎進行轉換,並在系統內形成規範。這部分工作對上層系統完全透明,只需要根據系統內的規範進行數據交互即可。所以,協議的解析是雙向的,由內向外,以及由外而內。

指令執行引擎(Command Executor)。在這個組件中會維護一份最新的「指令集」,每條指令都有特定的功能,依靠協議解析引擎,對應到不同的設備上的不同功能。

數據採集器(Data Collector)。顧名思義,這個組件的主要任務,是收集來自設備的所有數據,配合日誌服務進行記錄。數據採集器大致可以分為兩類:即時性和非即時性,根據業務需求響應不同時效性的採集器。

日誌服務(Logger Service)。這部分記錄的日誌有兩種類型:數據型,設備型。日誌的儲存形態不在本篇範疇,這裡著重闡述一下這兩類數據。

- 數據型日誌記錄的是流經控制層的數據,分為三種:
  1. 源數據,亦可稱之為「裸數據」,這一部分數據沒有經過任何的加工,從各個設備直出;

② 結構化數據,這部分數據是最接近業務數據的,對源數據進行了粗加工形成的;

③ 業務數據,根據系統的業務需求,對結構化數據做了進一步整合和加工形成的。

- 設備型日誌記錄的,是接入平台裡的設備相關的數據,分為兩種:
  1. 設備狀態,記錄的是設備狀態流數據;

② 指令收發,記錄的是中控平台對設備指令的收發數據。

管理工具套件(Management Toolkit)。這部分可以認為是中控平台的增值服務,優先級最低,不過想像的空間也是很大的。我打算將其設計成一個可響應Terminal命令的服務,比如獲取當前連接數,最大連接數是多少,指令集配置,發送指令給設備等等。

3) 業務處理器,這個是與業務相關的角色,可以根據實際業務需求去設計。我在設計業務處理器的時候,是以設備為中心的,再去擴充其他功能。如下是一張業務處理器的拓撲圖,具體的業務需求就不再展開敘述了。


業務處理器拓撲圖


4) 設備管理系統(Management System),這部分,我認為要做到兩個「可視化」:數據可視化,設備可視化。「數據可視化」比較好理解,就是數據的整合及其圖形化表示,當然,數據的來源可以是即時的,也可以是離線加工過的,這個業界都有成熟的解決方案。

還有一個就是「設備可視化」,這個主要是給普通使用者,一個比較友好的操作體驗,將設備具象化,點擊不同的按鈕,可以觸發其對應的功能。當然,對於專家使用者,也可以提供站內 Terminal,直接使用命令與設備進行交互。


3 設備管理系統兩個可視化」


5、總結
整篇文章闡述了設備 Gateway 的四層結構,並分兩個層面深入分析設備 Gateway 的系統架構。通篇沒有涉及具體技術細節,因為這是技術架構層面的內容了,定當另起新篇闡述之。

0 意見: