IOT語義交互性之交叉
這個系列文章描述了一個單一的語義數據模型來支持物聯網和建筑、企業和消費者的數據轉換。 這種模型必須簡單可擴展, 以便能夠在各行業領域之間實現插件化和互操作性。 對于一個目前從事智能硬件的老碼農，覺得這些文字具有積極的參考意義。本節討論業務和設備本體論的交叉點, 以及兩者的元素如何能夠提高可伸縮性。
- “Good design is good business.” – Thomas Watson Jr.
發展成為以IOT為中心的業務
對于用戶來說, 物聯網的真正價值并不在于遠程控制智能設備, 而是這些設備之間能夠相互良好的協作。 任何門的傳感器都能夠觸發開關而不依賴哪家設備制造商， 而且任何 HVAC 單元都應該能夠觸發服務請求或觸發更換空氣過濾器的命令。
這就擴大了智能設備和商業系統之間對語義互操作性的需求。 它還需要一個新的架構, 可以支持業務流程, 設備處理, 消除圍繞系統集成中間件構建的自定義系統的成本和復雜性。
這種新的架構必須使物聯網的模型和概念與商業應用平臺的模型和概念保持一致。 Gartner 預測, 到2020年, 大多數新的平臺服務(PaaS)應用將以IOT為中心。 這打亂了傳統的做法, 因為 PaaS 平臺將用于實現圍繞事件驅動的架構和物聯網數據，而不是以傳統主數據構建的業務應用程序。 這些以IOT為中心的業務應用程序反過來將轉變應用程序設計實踐, 將重點放在實時、豐富的上下文決策、事件分析、輕量級工作流程以及對網絡規模數據的廣泛訪問。
與此同時,"物聯網標準"和"業務標準"聯盟需要適當地調整他們的數據模型、概念和術語。 這些資產必須集中在一個可伸縮的語義互操作性中心點上, 并在應用程序(信息)層中以分布式來數據管理。
共同業務本體的跨行業領域需求
語義互操作性依賴于一個指定的本體來解釋交換數據的意義(上下文) , 并將其應用到一個有價值的目標。 這可以跨越多個系統、環境和工業。
針對特定行業的商業本體論(如金融業的 FIBO)和數據模型(如零售業的 ARTS ODM)有重疊的概念, 可以形成一個共同的商業本體論。 這個公共業務本體中的概念應該與一個上層本體(在第3部分 IOT語義互操作性之本體論)相一致, 就像根對象類, 這樣所有知識領域的所有對象都具有內在的互操作性。 這些共同的商業本體論為促進跨行業語義互操作性提供了基礎。
抽象(忽略不必要的細節的處理的一個廣義模型)和面向對象的分解(將一個大的系統分解成逐漸較小的類或對象)已經一次又一次地證明了它們在解決分布式系統不一致性方面的價值。 為了使一個公共業務本體與上層本體的類別適當地對齊, 通用業務概念需要通過追蹤與業務相關的數據到其原始對象類別來進行抽象和分解, 這可能是特定于行業的本體論或其他知識領域的一部分。 例如, 為了與上層本體對齊, 業務上顯示的數據元素不會被視為獨立"聯系人"類的屬性。 相反, 它們可以被分解成相關的頂級類的屬性(如系統、位置或聚會)。
如圖25所示, 一個電話號碼、街道號、互聯網域和電子郵件地址都是作為一種路由系統中端點的唯一"地址"屬性, 并由系統操作員(組織)管理。 電話號碼不是為"Contact"類定義一個"電話號碼"屬性, 而是可以定義為一種系統的屬性, 該屬性可以分配給一個設備。 這個設備可以被分配給一個派對（party）, 這個派對可以與另一個派對建立關系。
圖25 將名片分解為與上層本體對齊
在這個例子中,"Bob Smith"表示一個 person 的實例(對象) , 這是一種類型的派對（party）。 "Design by Design"表示一個組織對象, 它也是一種類型的Party。 鮑勃被授予"系統工程師"的角色, 他被設計得很聰明，他還被指定為一個移動設備, 由一個組織指定一個系統地址, 該組織本身被指定為"電話系統操作員"。
雖然這種層次的抽象和分解可能看起來很復雜, 但它實際上簡化了語義互操作性, 防止了碎片化。 反過來, 它消除了復雜的數據映射在獨立構思的對象類之間的需求。
位置 位置 位置
一個頂級的"位置"類和層次結構(圖26)可以支持地理位置的封閉領域(例如, Haystack 的地理位置) , 以及住宅或建筑工地內的空間細分(例如, 區域、樓層、套房或房間)。 一個位置可以分配給一個資產。
"Site"類(類似于 Haystack 的位置實體)可以包含支持郵政地址的唯一屬性(可以出現在商業名片上)。 Site可以被分配到一個當事人和一個交易(訂單, 裝運)。
圖27所示位置的例子顯示,"會議室"包含在一個城市內的一個場地內的一個"第四"樓層內的"會議室", 等等。位置類的"氣溫"屬性可以從分配給位置實例(四樓)的溫度傳感器中調節值(77.4 華氏度)。
郵政地址的定位實例可以反映郵政系統運營商組織(USPS)的所有權(所有者派對)。
圖27 位置顯示控制和所有權的示例實例
對象所有權的一方
一個頂級的派對類和層次結構(圖28)可以包含 Person 和 Organization 子類。 一個組織可以包括業務單元和團隊子類。
圖28 派對類的等級和關系
一方當事人能夠擁有法律所有權, 可以被分配到一個事務, 并指定一個對象的所有者(對象類的"所有方"屬性)。 通過這種方法, 每個對象都屬于一個締約方, 并且在創建時被分配給一個所有者派對。 所有者一方可以是創建對象的人, 也可以是與人或設備相關聯的組織。 所有者一方被賦予了所有當局對該物體的所有權力。
當事人也可以承擔一個或多個與一個或多個過程相關的角色。 "派對的角色"類(類似于 ARTS ODM)可以作為頂級關系類的子類來建模。
如圖29所示, 一個締約方角色的實例可以為另一方(所有者派對)指定一方的角色。 例如, 鮑勃 · 史密斯(一個人的例子, 是一種類型的聚會)可以被分配一個"系統工程師"的角色(出現在他的名片上)和一個"雇員"角色。 與鮑勃?史密斯(Bob Smith)(這種關系的所有者, 在他的簡歷上顯示)相比,"雇主"的角色可以轉換。
圖29 派對角色反向關系的實例
當一個"供應商"角色被分配給一個當事方(Arrow Electronics)時, 就可以建立貿易關系, 而反向的"客戶"角色則分配給另一方(通過設計來智能化)。
商業交易
一個頂級的事務類和層次結構(圖30)可以支持 B2B 事務和業務對消費者的交易, 包括訂單、裝運和付款對象。 作為一種替代的電子數據交換(EDI)方法, 這種面向對象的層次結構可以利用所有對象類共有的可互操作數據交換機制。
圖30 事務類層次結構和關系
交易實例可以定義一方之間與另一方(所有方)之間的商務交互(EDI 文檔)定義為與其有貿易關系的另一方(所有方)。
事務項類可以作為頂級關系類的子類建模。 事務項的多個實例可以包含在事務實例中, 以反映所交易的產品(貨物和服務)。
系統的系統
各種規模的企業都實施信息和自動化系統, 以有效和準確地控制其業務。 每個系統都包含一個本體或數據模型來管理、處理和存儲信息對象。
會計信息系統(財務 / 訂單管理系統)是一個核心的跨行業業務系統。 通過利用一個公共業務本體, 這個系統可以固有地與其他內部和外部系統相互操作, 這些系統也包含這個本體。
這種方法可以使企業有效地向多方數據共享過渡, 以滿足不斷變化的客戶需求和行業遵守情況(例如供應鏈可追溯性)。
一個頂級系統類和層次結構(圖31)可以支持系統的系統管理。 每個"組成"系統可以定義為"獨立可操作性", 但可連接一段時間, 以實現某一較高的目標[11]。 例如, 將倉庫管理系統與訂單管理系統連接起來, 可以消除重復的數據輸入, 并簡化訂單實現操作。
圖31 系統類和關系
自動化系統的事件處理
每個系統實例都可以包含 Process 實例集合, 其中可以包含規則實例集合。 進程實例可以根據其規則使用事件實例, 并從其操作中生成事件實例。 例如, 更改訂單的狀態(事件實例)可以觸發一個自動化過程, 生成一批貨物或付款。
系統根系的互聯網域
系統的一個互聯網域子類(圖32)可以將一個當事人(注冊人)分配給一個互聯網域(類似 IETF 的 EPP), 這可以為該方系統的系統提供一個根系。 例如, 互聯網域名"Smart-by-Design.com"，"com"可以被分配到"設計智能"組織。 智能設計的所有子系統都可以直接或間接地連接到"Smart-by-Design.com"。
圖32 域名系統為系統的根系指定一個當事人
系統屬性類和系統連接類可以模擬為頂級關系類的子類。 兩個類的多個實例都可以包含在系統實例中。
如圖33所示, 系統屬性實例可以在一個或多個代表系統進程的內部輸入 / 輸出，或與其他系統共享數據的一個或多個本體中的類屬性。 例如, 一個訂單管理系統可以引用事務類的"狀態"屬性和事務項類的"產品"屬性, 這兩個屬性都包含在公共業務本體中。
圖33 業務系統的系統屬性示例實例
如圖34所示, 系統連接實例可以反映基礎系統(通過設計智能)之間的連接和一個子系統(訂單管理)。 這個子系統反過來可以成為另一個系統連接實例中的基礎系統。 鏡像系統連接實例可以反映交叉對象系統之間的連接。 例如, 通過設計實現的智能訂單管理系統可以連接到 “Arrow 電子”的訂單管理系統, 以便能夠共享其系統屬性實例(如事務狀態)中定義的共同屬性交叉數據共享。
圖34 業務系統的系統連接示例實例
設備的產品和資產類別
頂級產品、資產類別和層次結構(圖35)可以支持生產單位(實例) , 這些生產單位是生產過程的所用材料, 并成為交易、轉化、使用或消費的資產。
圖35 產品及資產類別等級及多重繼承
大多數本體模型(例如 OMG 的 UML, Schema.org)允許類層次結構中的多重繼承: 類可以是多個類的子類。 這使得一個生產單位, 如一個設備, 既是一種產品, 也是一種資產。 它可以從"產品"類繼承"模型"屬性, 并從資產類中繼承"位置"屬性。 生產單位通常從制造商的庫存資產開始, 轉向為客戶的設備資產。
電子商務的共同產品本體
一個共同的產品本體(類似于 GS1的全球產品分類)可以根據產品的基本屬性及其與其他產品的關系對產品進行分類。 這個本體可以使交易伙伴以相同的方式將產品分組, 以便在多個電子商務網站上進行比較。
產品本體可以包括一個設備子類和層次結構(圖36) , 它定義了特定類別設備的屬性。 例如,"Pin Count"屬性可以包含在設備類中(適用于所有設備)和"最大輸出電壓"屬性, 可以屬于設備的傳感器子類。 一個電子商務網站(Arrow.com)可以顯示傳感器實例的繼承屬性, 作為傳感器模型之間的特征比較。
圖36 電子商務的設備類屬性
一個產品組件類(圖37)可以作為頂級關系類的子類建模。 產品組件的實例可以定義一個形成"產品的產品"的材料，或者組件的形式。 例如, 實例可以定義恒溫器(傳感器和執行器)的組件, 它本身被定義為冰箱的一個組成部分。
圖37 將冰箱定義為"產品的產品"的產品組件實例
聯合體概念可以與這個公共產品本體(圖38)對齊, 它包含一個帶有 Identifier、類和 Owner Party 屬性的根對象類。
圖38
替換標識符的屬性
任何一方可以根據標準方法(ISO, IETF)生成的通用(全局)唯一標識符(UUID)可以識別一個對象, 而無需依賴于中央注冊機構。 雖然 UUID 被復制的概率不是零, 它是如此接近零, 以至于可以忽略不計。 UUID 和 GUID 的應用非常普遍, 許多計算平臺為生成它們提供了支持。
然而, 使用由注冊機構(組織)控制的編號方案生成的標識符, 也可以唯一地識別相同的對象。 例如, GS1維護的"ID 密鑰"編號，這些密鑰能夠獨特地識別支持全球供應鏈分布式系統的產品、資產、位置和事務類的實例。 此外, 任何組織(例如產品制造商、零售商或業務單位)都可以維護自己的編號模式(例如產品模型) , 該模式在其內部系統中唯一地標識對象。
為了有效地管理這些"備用標識符", 屬性實例可以定義一個唯一的類屬性, 以支持由一方(所有方)控制的特定編號模式。 在圖39中, 一個包含在產品類中并由 GS1擁有的屬性實例, 用于標識產品實例的全局交易識別號(GTIN)的每個長度。
圖39 支持備用標識符的示例屬性實例
如圖40所示, 一個產品實例可以通過其繼承的對象類中 Identifier 屬性以及在產品類(Model, GTIN-8, GTIN-12, GTIN-13等)中的其他標識符屬性。
圖40 具有代表備用標識符屬性的產品實例
向物聯網擴展一個公共業務本體
產品向智能連接設備的發展——越來越多地嵌入到更廣泛的系統中——正在從根本上塑造公司和競爭[12]。
智能連接產品需要重新思考設計。 在最基本的層面上, 產品開發正在從主要的機械工程發展到真正的跨學科系統工程, 可以支持一個系統的系統, 如圖41[13]所示。
圖41 將物聯網轉移到系統系統中
與系統的系統一樣, 物聯網組件是異構的, 自主的, 能夠通信, 分布式, 操作和管理上獨立。 這兩個領域都在動態的情況下進化和運行, 從而導致新的行為。 在這種情況下, 物聯網可以被看作是一個設備系統[14]。
隨著業務系統和平臺被重新設計成以IOT為中心, 智能設備可以被設計成以系統為中心, 并利用一個共同的業務本體提供業務和設備系統之間的內在互操作性。
控制器是一種設備(典型的微處理器或計算機) , 它監視和改變連接其控制系統的元器件(傳感器、執行器)的運行狀態(例如溫度或速度屬性)。
這些設備的控制屬性可以在共同設備本體的類中定義(圖42)。 在設備控制器子類中的"系統"屬性可以使系統分配給 Controller 實例。
圖42 設備本體中包含設備系統屬性
系統屬性類可以包括支持控制器設備系統的實例(圖43)。 這些實例可以引用共同設備本體中的類屬性, 該屬性表示系統進程的內部輸入 / 輸出，或與其他系統的共享數據。 例如, 一個氣流控制系統可以引用傳感器子類的"溫度"屬性、控制器類的"時鐘"屬性以及執行器子類的"速度"屬性。
圖43 設備系統的系統屬性實例
系統連接類可包括與業務系統相連的支持設備系統的實例(圖44)。 例如, 實例可以反映空氣流量控制系統和 HVAC 系統之間的連接, 這兩個系統連接到智能建筑系統，該系統連接到由智能設計實現的設施管理系統。
圖44 設備和業務系統的系統連接實例實例
智能建筑系統可以包含一個進程, 該過程可以改變由分配給控制裝置，連接空氣流量是控制系統所控制的風扇電機(一個組件設備)的"速度"屬性。 這個過程可以產生一個事件實例, 當觸發事件實例發生時(如氣溫變化)時, 該事件實例可以改變風扇速度, 這種情況可以通過流程規則進行監控。 舉例來說, 當智能建筑管理「第四」樓層位置的「氣溫」屬性超過74華氏度的設定值, 時間為上午7時30分至下午6時30分(過程規則)時 , 把風扇轉速改為30每分鐘轉速。
將組織數據模型與常見的本體結合起來
組織聯盟可以通過抽象和分解不同的數據模型來加速采用共同的本體論, 使其以系統為中心, 并調整其概念和術語。 例如, Zigbee集群，開放連接基金會(OCF)的"資源"和藍牙的"配置文件"可以轉向一個共同的"系統"概念 / 術語, 包括"屬性"和"過程"。
可以對聯合體概念進行對齊, 形成一個共同系統本體(圖45)
圖45 共同系統本體的類對齊
可以對聯合體對象進行對齊, 以形成共同系統本體的實例(圖46)
圖46 一個共同系統本體的對象分解和對齊
可以對聯合體概念進行對齊, 形成一個通用設備本體(圖47)
圖47 共用設備本體的類和屬性對齊
一張物聯網數據語義注釋的地圖
數據映射可以在兩個不同的數據模型或本體之間聯系數據元素。 例如, 需要與貿易伙伴發送和接收業務交易的企業可以從其業務系統的數據模型創建數據映射到 EDI 標準的數據模型。
數據地圖也可以被一個控制器設備使用, 它接收來自一個資源稀缺的傳感器的數據, 該傳感器需要"語義注釋", 以便在標準時間序列內提供完整的上下文。
數據映射類(圖48)可以作為頂級關系類的子類建模。 數據地圖實例可以將傳感器對象(zn3-wwfl4)和屬性(溫度)聯系到位置對象(四樓)和屬性(氣溫)。 通過引用這個數據映射實例, 控制器可以用包含在數據映射實例中的語義來注釋從傳感器收到的語義, 以填充時間序列的元數據。
圖48 支持語義注釋的對象屬性數據映射
設備和業務事件的通用時間序列
為了創造價值, 物聯網設備生成的數據越來越規范化為時間序列數據(標有時間戳的數據) , 并以定期間隔(基于間隔)或者基于狀態(或值)的更改(基于事件)。
時間序列類(圖49)可以作為頂級事件類的子類建模。 時間序列實例可以被有效地索引、共享、存儲、查詢和分析。 隨著業務應用程序(系統)變得越來越以 IOT為中心, 并圍繞事件驅動的架構構建, 來自業務事件的數據也可以歸一化為時間序列數據。 一個通用時間序列類可以支持反映對象狀態(屬性值)變化的設備和業務事件。
圖49 設備和業務事件的公共時間序列示例
例如, 時間序列實例可以從傳感器值中反映位置的氣溫變化, 從而產生反映冷卻風扇速度變化的實例, 從而產生一個反映風機發動機故障的實例, 從而產生反映制造商更換零件訂單和服務工作順序的實例。 時間序列實例還可以反映與貨幣單位有關的貨幣單位的換算系數(貨幣兌換率)的價值變化, 這種變化會影響到替換部分的價格。
總的來說, 本文中討論的概念(類)可以形成共同的跨行業本體論, 支持業務和設備的語義和過程。 這可以消除自定義系統集成的成本和復雜性。
References
10 Lheureux, Benoit, Gartner Research, March 2016
11 Jamshidi, M., Systems of Systems Engineering: principle and applications, CRC Press, 2009.
12 Porter, Michael E. and Heppelmann, James E., "How Smart, Connected Products are Transforming Companies", Harvard Business Review, October 2015
13 Bleakley, Graham and Hause, Matthew, "Systems of Systems Engineering and the Internet of Things", OMG webinar Nov, 8 2016
14 Alkhabbas, F., Spalazzese, R., and Davidsson, P., IoT-based Systems of Systems, Malmo University, Sweden
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
