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

3S MARKET

2019年10月28日 星期一

What is an IoT Gateway? (SAP EA Explorer - Short Video)

來源:知乎

0、寫在前面的話
坦白來講,我對物聯網行業沈澱較少。

做軟體出身的我,之前也學過一些單機的知識,還有射頻, ZigBee 諸如此類的無線傳輸協議,因為那段時間「智慧家庭」火了,年少無知的我也跟著瘋了,然後就沒有然後了……
回想自己以前對技術的狂熱,還是值得肯定的,但是那種近乎盲目的追求,就有點過猶不及了。

總之,學到的新技術或者新概念,需要及時去實踐,去落地,長時間的擱置會導致最終一場空,這種到頭來一無所有的感受,對自己的積極性也是一種打擊。

1、背景介紹
如今,隨著公司業務的不斷擴大,有一批設備需要對接到我們的平台裡,所以我嘗試著去設計一下,我們公司的設備 Gateway 系統架構。( Gateway,台灣稱為閘道器,對岸中國一般稱網關)

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

① 設備安裝/綁定。

② 設備數據即時上報

③ 設備維







1 設備 Gateway 核心功能


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

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







2 設備 Gateway 四層結構

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

現在對每個層次做一個簡單的介紹:

數據層。處於底層,整個系統的數據源頭,很明顯是一個最基礎的層次。

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

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

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

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

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

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

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







3 設備 Gateway 系統架構(level-1)


從圖中不難看出,整個設備 Gateway 存在 4 個關鍵角色。

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

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

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

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

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

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

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

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







4 「子設備」概念

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

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







5 中控平台組


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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







6 業務處理器拓撲圖

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

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







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


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

希望能對你有所幫助!

0 意見: