這個系列文章描述了一個單一的語義數據模型來支持物聯網和建筑、企業和消費者的數據轉換。 這種模型必須簡單可擴展, 以便能夠在各行業領域之間實現插件化和互操作性。 對于一個目前從事智能硬件的老碼農，覺得這些文字具有積極的參考意義。這一部分討論通用的數據格式和應用程序編程接口(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