• 沒有找到結果。

開放式物聯網基礎建設之技術發展

在文檔中 期末報告(定稿) (頁 97-106)

第四章 實施方法

4.4 研發三維地形圖資與物聯網之整合及應用

4.4.2 開放式物聯網基礎建設之技術發展

除前述 OGC SensorThings API 標準之物聯網網路服務層標準外,物聯 網之基礎建設架構亦須考量裝置層、閘道器層、及各層級間之通訊標準,

如圖 4-4-2-1 所示。裝置層主要為物聯網裝置之所在,包含裝置之感測器及

85

致動器。閘道器層主要以在地通訊網路與物聯網裝置連結,輔助裝置與與 網路服務溝通。其在地通訊網路協定包含舊有的 ZigBee、Bluetooth 與發展 中之 NB-IoT、LoRaWAN、SigFox 等。而網路服務層則作為物聯網資源與 前端應用層之主要接口,提供物聯網感測資料之倉儲管理及物聯網裝置控 制任務之轉傳功能。因此,為使本計畫之三維地形圖與物聯網技術整合完 整,本項工作進行物聯網開放式基礎建設方案之探討與技術發展。

圖 4-4-2-1、物聯網架構

本工作項目為探討 OGC SensorThings API 標準與閘道器層及裝置層之 通訊協定,進而有效串接組合完整的物聯網基礎建設。使用兩種方案進行 測試,第一種方法為基於 OGC SensorThings API,提出相同標準生態系統 之閘道器層與裝置層通訊協定,以達物聯網資訊之自動連結與流通。第二 種方法為為結合 OGC SensorThings API 標準與其他階層之開放式標準,例 如經濟部資策會推動之 oneM2M 閘道器層標準。透過此項工作之執行,預

86

期可提出未來物聯網開放式基礎建設架構之有效方案。

第一種方法為使物聯網裝置與網路服務自動連結,本工作項目設計(1) 裝置描述文檔,以說明裝置之詮釋資料及能力、(2)裝置與閘道器之預設通 訊協定,以自動化建立連結、及(3)自動註冊與資料傳輸程序。由於此方法 為基於 OGC SensorThings API 標準之通訊協定,裝置描述文檔直接使用 SensorThings API 之資料模型及 JSON 編碼最為直接,其資料模型如圖 4-4-2-2 所示。

圖 4-4-2-2、 OGC SensorThings API 第一版資料模型

而本次測試之閘道器與裝置無線通訊協定為 ZigBee。ZigBee 為低功耗、

低速率且低成本之無線通訊協定,為感測器網路常見之通訊協定。為使裝

87

置與閘道器可自動化建立連結,本工作項目制定 ZigBee 需要的預設設定,

包含 64-bit PAN ID 及 64-bit 位址。針對自動註冊與資料傳輸程序,我們設 計裝置及閘道器溝通之自動化程序,如圖 4-4-2-3 所示。以上設計已透過 Arduino UNO、DHT22 溫濕度感測器、及 ZigBee 通訊模組實作驗證。所建 造之物聯網裝置可自動與附近的閘道器建立連結,並進行註冊及資料傳輸,

使用者可直接透過 OGC SensorThings API 網路服務取得感測資訊。

圖 4-4-2-3、物聯網裝置自動註冊與資料傳輸程序

第二種方法連接 OGC SensorThings API 與 oneM2M 標準。欲達成不同 層級標準之串接,主要需考量之因素包含資料模型之對應與包裝方式、資 料模型的自動轉換機制。oneM2M 所制定之資料模型如圖 4-4-2-4 所示,以

88

CSEBase 為服務的根目錄,內含多個 Application Entity (AE)用以代表物聯 網裝置,而一個 AE 可包含多個 container 用以儲存該裝置之不同資訊。一 個 container 可含多個 contentInstance 以提供確切的資料內容於 contentInfo 內。此外,各項資源皆含 resourceName 作為唯一辨識符。由於 oneM2M 制 定此資源樹架構時並無規定各項 container 與 contentInstance 所儲存資料之 語意,oneM2M 之資料模型可視為具有彈性,開發者可自行設定所儲存之 資料及其儲存方式。

圖 4-4-2-4、oneM2M 資料模型

由於 oneM2M 資料模型具有彈性,本項工作的標準整合策略為制定

89

SensorThings API 於 oneM2M 之子資料模型(data model profile),進而在 oneM2M 儲存可對應至 SensorThings API 資料模型之內容,再透過轉換程式 自動化將 oneM2M 資料匯入至 SensorThings API 網路服務。因此,本項工 作的重點在於制定此子資料模型,如圖 4-4-2-5 所示。首先,AE 設定為物 聯網物件,對應至 SensorThings API 之 Thing,CSEBase 可存有多個 AE 代 表不同的物聯網物件。各個 AE 使用五類 container 儲存該物件之不同屬性,

個別逐點敘述如下:

 「Thing Metadata」container:儲存 SensorThings API 中 Thing 實體 之屬性。

 「 Datastream Metadata 」 container : 此 container 存 有 多 個 contentInstance 對應至各個 SensorThings API 之 Datastream,且以個 別 Datastream 之唯一識別符作為 resourceName,如「Datastream1」、

「Datastream2」。contentInstance 內將儲存 SensorThings API 中 Datastream、Sensor、ObservedProperty 此三類別之屬性。

 「Location」container:此 container 存有多個 contentInstance 描述該 Thing 在各個時間點之 Location,因此所儲存之內容包含 Location 之屬性以及 time 時間屬性。此 container 之資訊對應至 SensorThings API 之 Location 及 HistoricalLocation。

 「FeatureOfInterest」container:此 container 存有多個 contentInstance

90

描述所觀測之特徵物(Feature of Interest)屬性,提供後續 Observation 參照整合。

以 Datastream 唯一識別符為名稱之 container:此類 container 之多個 contentInstance 儲 存 該 Datastream 之 觀 測 事 件 (Observation) 內 容 。 除 了 SensorThings API 之 Observation 屬性外,此 contentInstance 亦含有該 Observation 所觀測之特徵物(FeatureOfInterest)位址,以描述 Observation 與 FeatureOfInterest 之關係。並且,透過使用 Datastream 唯一識別符作為 container 名稱,亦可建立 Observation 與 Datastream 間之歸屬關係。

91

圖 4-4-2-5、oneM2M 之 SensorThings API 子資料模型

本項工作之實作測試以開源 oneM2M 實作 Eclipse OM2M 進行,並開

container (Thing Metadata)

contentInstance Things properties container

(Datastream Metadata) contentInstance

(Datastream1) contentInstance

(Datastream2)

DataStream, Sensor, ObservedProperty

properties DataStream, Sensor,

ObservedProperty

(Location1) Location properties + time

container

(Location2) Location properties + time

container

Observation properites + FOI URL Observation properites

+ FOI URL Observation properites

+ FOI URL

92

發自動化轉換程式將 oneM2M 內根據所提子資料模型儲存之資料轉換至 SensorThings API 網路服務。圖 4-4-2-6(a)為於 oneM2M 平台創建 AE/Thing 之 HTTP POST 請求範例,圖 4-4-2-6 (b)為於 OM2M 平台所創建的一個空氣 品質測站範例,其中所選取之 Thing_Metatdata 之「con」(contentInstance) 描述該 Thing 之屬性。圖 4-4-2-6 (c)為透過所開發之自動轉換程式將圖 4-4-2-6 (b)空氣品質測站案例轉換至 SensorThings API 服務之成果。

整體而言,本工作項目探討兩種開放式物聯網基礎建設之建立策略,

一 種 為 延 伸 SensorThings API 至 閘 道 器 層 及 裝 置 層 , 一 種 為 整 合 SensorThings API 與 oneM2M 標準。此兩種策略皆可達成開放式物聯網基礎 建設之願景,然而此兩種策略在實務上皆仍須經標準或規範制定流程進行 研討與確認,才可建立開放式物聯網基礎建設參與者之共識。

(a) oneM2M 創建 AE 之請求範例 (b) OM2M 平台檢視所創建之空氣品質測站資訊

93 (c) 自動轉換至 SensorThings API 服務之 Thing 實體

圖 4-4-2-6、SensorThings API 與 oneM2M 整合範例

在文檔中 期末報告(定稿) (頁 97-106)