IOT語義互操作性之API介面

這個系列文章描述了一個單一的語義資料模型來支援物聯網和建築、企業和消費者的資料轉換。 這種模型必須簡單可擴充套件, 以便能夠在各行業領域之間實現外掛化和互操作性。 對於一個目前從事智慧硬體的老碼農，覺得這些文字具有積極的參考意義。這一部分討論通用的資料格式和應用程式程式設計介面(API)，以及如何利用這些共同的本體。

當你剛開始嘗試解決一個問題時, 
你提出的第一個解決方案是非常複雜的,
大多數人都會停下來。 但是如果你堅持下去, 
面對這個問題, 剝掉更多的洋蔥層,
你會經常得到一些非常優雅和簡單的解決方案。 
大多數人只是沒有時間和精力去那裡。 ————史蒂夫 · 賈伯斯

在物件世界中管理資料

在新興的數字世界中, 數十億人、系統和裝置將實時互動, 需要在分散式資料管理、互操作性和基於規則的事件處理方面採取新的破壞性創新方法。

除了統一本體論、”物聯網標準”和”業務標準”聯盟之外, 還需要匯聚在一個共同的資料交換格式和 API 模型上, 以支援基礎廣泛的跨行業領域用例之間的外掛和播放互操作性。

分散式資料管理和互操作性依賴於一個共同的本體(語義)和通用資料格式(用於語法) , 使服務能夠識別和解釋在連線系統之間交換的結構化資料。

在本文中,”物件管理”是指在分散式環境中建立、儲存、更新、訪問和共享本體物件例項狀態的機制。

什麼是服務？

“服務”一詞根據具體情況有不同的含義。 因此, 圍繞服務的概念存在著一些混亂, 因為人們試圖區分應用服務、域服務、基礎設施服務、面向服務的體系結構(SOA)服務等。 在所有這些情況下,”服務”一詞是有效的, 但作用不同, 可以跨越應用程式的所有層次[15]。

在領域驅動設計(DDD)中, 一個”域”服務以領域概念(本體類)為基礎, 非常細粒度(如 微服務) , 可以被認為是一種過程的封裝。 “應用程式”服務為域服務提供了一個託管環境, 並將域的功能作為一個 API 公開給外部服務。 應用程式服務根據一個公共資訊模型的標識值和原始資料結構(在上層本體中)。

在一個模糊世界的模型服務

考慮到物聯網的大量資料以及對實時通訊流的需求, Gartner 預測, 到2022年, 75% 的企業生成的資料將在資料中心或雲以外建立和處理。 很明顯, 只有雲端計算的方法不再能夠跟上必要的體積、延遲、可靠性和安全性的挑戰。

一個分散式計算模型(如fog computing)可以通過提供一種標準的、通用的方式來管理、管理和分配必要的資源和服務, 使數字世界具有功能性和互操作性, 從雲到物聯絡起來(圖50)。

圖50 語義互操作性和霧計算服務模型

該模型可以”混合”流行的體系結構樣式(如 DDD、模型驅動設計、事件源和命令查詢責任分離CQRS)來定義一個可互作業系統系統中物件管理的簡單和可伸縮應用服務。 這些系統可以跨越物聯網裝置、商業、車輛和城市的子系統。 這些服務可以利用上層本體和資訊模型(見第二部分)來支援系統連線、統一資料交換、事件和查詢處理、單元和識別符號轉換以及語義註釋。 為了擴充套件規模, 這些服務必須是穩定, 不變而且獨立,從邊緣控制器到雲伺服器，可以嵌入到任何型別的機器。

該模型可以定義一組物件管理服務(類似於 IETF 的可擴充套件供應協議(EPP)) , 它們沒有明確地與特定物件繫結, 並且可以擴充套件到所有本體類中的物件。 雖然物件管理與物件導向程式設計相似, 但該服務模型可以代表類似於模型驅動開發程式設計中的後設資料抽象。 這些服務可以建立後設資料, 並在執行時解釋該後設資料。 代表本體的後設資料可以在一個完全抽象於任何程式設計環境的儲存庫中維護。 底層程式碼作為服務的平臺(例如 Mendix)可以利用這種服務模型, 在完全通過後設資料解釋執行的應用程式之間提供固有的互操作性。

雖然服務和安全模型之間存在著很強的關係, 但是該系列中的這一部分將側重於與語義相關的服務, 這與任何特定的安全模型無關。

有效訊息載荷的網格

為了創造價值, 物聯網裝置生成的資料越來越多地在一個時間序列內進行時間戳標註, 並在間隔或狀態變化時傳輸。 隨著業務應用程式越來越以IOT為中心, 並圍繞事件驅動的架構, 來自業務事件的資料也可以構建為一個時間序列。 查詢響應可以包括基於這些事件更改的裝置和資訊物件的當前狀態。 時間序列和查詢響應資料代表了大多數分散式資料交換, 並且最有效地包含在網格(表格)結構中。

一個網格(類似於Haystack網格)可以作為分散式資料管理的核心資料格式, 可以採用適合於特定通訊協議的同步格式傳輸(圖51)。 例如, 一個網格可以編碼為一個 JSON陣列(二維) , 用於通過 HTTP 訊息傳輸。 或者它可以編碼為一個簡潔的二進位制物件識別(CBOR)陣列, 用於通過 CoAP 傳輸。

圖51 連線系統交換序列化二維網格中的資料

由組織機構定義的資料交換服務支援的同步格式各不相同(圖52)。 最初主要為伺服器實現設計的服務(GS1 EDI 和 IETF EPP)支援 XML, 而那些針對資源受限裝置的服務支援更多的壓縮編碼格式(如 JSON 和 CBOR)。 網格資料可以被編碼到這些格式中的任何一個。

圖52 訊息負載的資料序列化 / 編碼格式

應用服務的通用 API 閘道器

通用的 API 閘道器可以在控制器裝置中實現, 作為連線系統所有入站訊息的單一入口, 可以在控制器裝置中實現一個通用 API 閘道器, 作為連線系統所有入站訊息的單一入口點。 閘道器可以對每個訊息進行身份驗證, 並將去序列化的網格有效負載轉發到應用服務, 這反過來又可以呼叫由閘道器處理生成出站訊息的其他服務。

通過將一個普通的 API 作為所有控制器裝置的前端, 可以抽象出不同裝置型別和微服務分割槽的複雜性。 然後, 該裝置可以轉換為服務(device-as-a-service) , 並被其他服務使用。

基於網格資料的型別, 閘道器可以呼叫單獨的事件和查詢處理服務(類似於 CQRS 架構) , 該服務可以更新和檢索在”事件儲存”中持久存在的物件的狀態(圖53)。

圖53 事件 / 查詢責任分離和與事件儲存的互動

一個時間序列的事件儲存

自動駕駛的 Teslas、自主的華爾街交易演算法、智慧家居和同一天訂單滿足服務有什麼共同點？

這些應用程式依賴於一種資料的形式, 這些資料可以測量事物隨著時間的變化, 時間不僅僅是一個度量, 而是一個主軸。 這是時間序列資料。 它開始在我們的世界中發揮更大的作用, 遠遠超出感測器資料流的範圍。 事實上, 時間序列資料庫(TSDBs)已經成為增長最快的資料庫類別之一, 可以有效地索引、查詢、共享和分析。

當應用於”事件源”的概念時, 可以將 TSDB 視為一個”事件儲存”, 它將物件狀態作為一個時間序列中的一系列狀態變化事件。 當一個物件的狀態發生變化時, 一個新的事件被追加到事件儲存中, 這是原子本質。 通過禁止事件的更改或刪除, 事件儲存可以提供對物件進行所有更改的可靠審計日誌。

在圖54中, 一個事件儲存從9 / 18的一個事件中反映了 Location 物件(例項)的建立, 該事件在9 / 18日02:15分分配給新物件的所有方。 該事件還為該物件指定了一個識別符號和類, 這是它的主鍵。 這個金鑰包含在隨後的所有事件中, 這些事件通過給屬性賦值來改變物件的狀態。 位置物件的當前狀態可以從物件的每個屬性最新事件派生出來。

圖54 通過在事件儲存中的時間序列事件獲取 Location 例項(物件)的當前狀態

事件可以通過將一個布林值分配給根物件類的”已刪除”屬性, 從而刪除(或刪除)物件。 通過這種方法, 事件和事件處理可以有效地建立、更新和刪除物件, 取代對單獨命令和命令處理的需求(讀取可以通過查詢和查詢處理來處理)。

區塊鏈 還是 事件儲存

區塊鏈和事件儲存都是資料儲存機制, 它們可以提供分散式環境中物件狀態變化的附加審計線索。

雖然區塊鏈正在享受最近的炒作, 但事件儲存 / 事件訂閱方法可以提供許多封鎖鏈承諾的好處, 沒有開銷、社群建設和成為礦工的風險。

區塊鏈是基於分類賬和交易的概念, 這些概念非常適用於金融業。 然而, 這些概念是否非常適合於支援一個可互操作的裝置系統呢？

“混合”可伸縮的方法可以結合事件儲存中物件導向事件的粒度與區塊鏈的反篡改驗證結合起來。

事件處理服務

代表時間序列事件的網格資料可以結構化為一種通用格式, 使所有事件消費應用和在控制器裝置上實現的域服務進行高效處理。 這個通用事件格式可以支援反映物件狀態(屬性值)更改的裝置和業務事件。 圖55中的頂部網格在這種格式中顯示了人可讀的值, 但實際值可以反映底部網格所示的機器可讀識別符號。

圖55 使用事件處理服務來從公共格式中保持時間序列事件

通用 API 閘道器可以呼叫事件處理服務來處理入站的時間序列事件, 並可以向連線控制器系統釋出出站事件。

事件處理器可以根據所有系統程式(例如微服務)的規則對事件進行處理, 這些事件可以發出新的事件(包括與 OCF post / response 類似的確認事件)。 事件處理器可以將事件釋出到事件儲存中以保持狀態(類似於 Haystack 的寫操作)。

一個基於上層本體的資料地圖可以被一個事件處理器引用, 該處理器接收來自稀缺資源的感測器資料。 然後, 事件處理器可以用資料對映例項中包含的語義來註釋從感測器接收到的語義, 以在公共事件格式中填充所有後設資料(圖56)。

圖56 使用事件處理服務和上層本體來註釋時間序列語義

這個註釋可以包括將特定於聯營集團的資料格式轉換為通用事件格式(圖57)。 例如, 一個溫度感測器可以提交一個分隔的名稱 / 值對的集合, 這些名稱 / 值對提供了除了值之外的語義。 這些資料可以轉換為僅包含值側的網格, 因為網格列定位對應於特定的資料元素。

圖57 使用事件處理服務將不同的事件格式轉換為通用格式

一個事件處理器可以參考系統屬性(圖58) , 該上層本體定義了讀 / 寫設定(類似 OCF 的只讀屬性)。 基於這些設定, 事件處理器可以監視(讀)和(寫)與控制器相連的元件裝置(感測器、執行器)的執行狀態。

圖58 使用事件處理服務獲取 / 設定基於系統屬性例項的讀 / 寫設定的風扇速度

例如, 如果一個系統屬性可以同時讀取和寫入風扇的速度屬性, 那麼事件處理器可以從風扇中檢索當前值(類似於 OCF get) , 並根據時間序列事件設定其值(類似於 OCF post)。

基於釋出/訂閱的系統連線

事件儲存可以作為”服務登錄檔”, 儲存定義系統連線和連線系統屬性的事件。 以上層本體為模型的系統連線可以表示實時資料訂閱(類似於 Haystack 的”watch”)。 當一個裝置用另一個裝置啟動系統連線(EPP 會話)時, 該裝置可以響應其系統屬性。 裝置可以交換包含系統之間共同屬性的事件和查詢。 這些屬性代表系統程式的內部輸入 / 輸出。

圖59 使用事件儲存(登錄檔)的事件處理服務, 向具有共同屬性的連線系統釋出事件

例如, 控制器的 HVAC 系統可以連線到另一個控制器的氣流控制系統。 這兩個系統都可以引用在一個公共本體中定義的”風扇”裝置的”速度”屬性。 HVAC系統的一個過程(域微服務)可以產生一個時間序列事件, 當觸發事件發生時(如氣溫變化)時, 可以改變風扇速度。 系統控制器的事件處理器可以將此事件釋出到 Airflow 控制系統控制器, 該控制器呼叫其事件處理器來改變連線風扇電機的速度。

數字雙胞胎的狀態管理

從設計到預測分析,”數字雙胞胎”的使用正變得越來越普遍。 這個概念非常簡單——基本上, 雙胞胎指的是一個實際物理資產的動態軟體模型(數字例項化)。 該模型能夠實時公開裝置及其連線系統的內部工作, 並與其進行實時互動。 數字雙胞胎可以整合感官和上下文資訊, 使各組織能夠從資產資訊中受益。 最終的結果是有可能創造更高的資產業績, 並使製造商能夠管理服務裝置。

一個由物件管理服務組成的共同服務模型可以通過支援同步和釋出狀態變化來管理數字雙胞胎的狀態(類似於 Eclipse Ditto)。

查詢處理服務

網格資料可以表示查詢請求和響應。 查詢請求可以結構化為一種通用格式, 使得應用程式服務可以在控制器裝置上實現。

通用 API 閘道器，可以呼叫查詢處理服務來處理在公共查詢格式中的入站查詢請求(圖60)。 查詢處理器可以從符合查詢條件的事件儲存中檢索相關物件的當前狀態, 並將出站查詢響應返回到請求服務。

圖60 使用查詢處理服務和通用查詢格式從事件儲存中檢索物件狀態

查詢處理器可以在上層本體中引用詞彙條款(圖61) , 為全域性應用程式提供多國家語言支援。 通用查詢格式可以包含一個元素, 該元素指定查詢響應中所包含資料的人類語言。 例如, 如果圖61中所示查詢指定了”西班牙語”語言, 則在響應網格中返回的樓層名稱將以西班牙語而不是英文出現。

圖61 使用查詢處理服務和上層本體檢索請求語言中的詞彙項

用於識別符號轉換的服務

應用程式服務可以在上層本體中引用屬性和單元(圖62) , 以轉換包含在時間序列事件中的備用識別符號。

圖62 使用應用程式服務和上層本體在時間序列事件中轉換備用識別符號

例如, 事件處理器可以呼叫一個服務來轉換由屬性識別符號限定的替代單元識別符號(如 “degF”)。 該服務可以引用該單元物件, 該物件包含帶有交替識別符號(“degF”)的標識屬性(“ISO 程式碼”)。 該服務可將事件中單位識別符號的值轉換為單元物件的主識別符號(例如 0 華氏度)。

另一個例子是, 轉換服務可以在 RFID 感測器生成的時間序列事件中轉換用於識別”物件”和”值”元素的替代識別符號。 圖63中的”價值”元素包含一個可交替的位置識別號(“0123456789012″) , 該識別符號符合 GS1的 EPCIS 標準(例如”urn: epc: id: sgln”)。 轉換服務可以引用位置物件, 其中包含帶有備用識別符號(“012345…”)的標識屬性(“GLN”)。 該服務可將事件中的”Value”元素轉換為 Location 物件的主識別符號(“3100 Main…”)。

圖63 將 GS1 EPCIS 事件與通用事件格式對齊並轉換 GS1鍵

單位轉換服務

應用程式服務可以參考以上層本體為模型的測量單位, 以轉換包含在時間序列事件中的”Unit”和”Value”元素。

例如, 一個事件處理器可以通過引用相關單元物件的”轉換因子”和”偏移”屬性值, 從而將圖64中的溫度值(“77.4”)從華氏轉換為攝氏。

圖64 利用應用服務和上層本體在時間序列事件中轉換測量值和單位

領域特定本體的領域微服務

雖然應用程式服務的目的是穩定和不變的, 但隨著流程和規則的演變, 可以動態地實現域微服務, 以有效實現系統所有者(當事方)的目標。

每個系統都可以包含一個微服務集合(過程和規則的封裝) , 其中引用了特定領域本體中的屬性(例如, 醫療、零售、智慧建築等)。 這些狹義的、合作的微服務可以根據規則消耗時間序列事件, 並從它們的行動中產生時間序列事件。

事件處理器可以為複雜事件處理協調域微服務的執行。

圖65提供了一個域微服務的例子, 該服務可以引用在特定領域本體中建模的場景定義, 以根據觸發事件(如時間變化)改變位置的”場景”。

圖65 使用域服務和本體來改變辦公室套件中的”場景”

另一個域微服務可以引用以公共業務本體為模型的業務資訊物件, 以生成事件來定義基於故障裝置觸發事件的替換順序(圖66)。 同樣的控制器可以改變連線元件(圖論)裝置(如感測器和執行器)的狀態, 也可以用來改變資訊物件(如訂單)與連線業務系統的狀態。

圖66 使用域服務和公共業務本體從裝置故障中生成替換順序

一個共同的服務模型和共同的本體論可以形成一個”公共物件管理框架”, 支援系統的語義互操作、對等對等系統。 這個框架可以分解資料倉儲, 消除複雜的系統整合, 並且只使用後設資料來統一資訊空間。

References:

15 Vernon, Vaughn, Implementing Domain-Driven Design, Addison-Wesley, 2013

16 Murdock, Paul, Davies, John, et al., “Semantic Interoperability for the Web of Things”, ResearchGate, Aug 2016

17 Hambley, Lee, “Blockchain or Event Sourcing”, July 2017

18 Richardson, Chris, http://microservices.io

19 Byers, Charles., Swanson, Robert, et al., OpenFog Reference Architecture, OpenFog Consortium, Feb 2017