IOT語義互操作性之語義
這個系列文章描述了一個單一的語義數據模型來支持物聯網和建筑、企業和消費者的數據轉換。 這種模型必須簡單可擴展, 以便能夠在各行業領域之間實現插件化和互操作性。 對于一個目前從事智能硬件的老碼農，覺得這些文字具有積極的參考意義。這一部分定義了數據語義。
物聯網抽象層和互操作性程度
互操作性, 或計算機系統或軟件交換或使用資訊的能力[1] , 是參與如今信息經濟所有設備的一項要求。 傳統上, 互操作性主要是在網絡通信背景下定義的。 但隨著從智能家居、智能建筑到智能能源、零售以及醫療保健和交通等行業, 數以百萬計的設備正在連接, 因此現在需要一個更廣泛的定義, 來考慮互操作性對系統以及系統性能的跨領域影響。
著名的網絡互操作性框架是OSI模型。 OSI 模型通過七個不同的抽象層提供了一個互操作性的框架, 這些抽象層通過分享軟件中的應用程序數據(第7層)從物理媒體中的底層傳輸(第1層)。 這些圖層及作用的簡要描述見圖1。
圖1 | OSI 模型概述了電信和計算網絡互操作性的七個抽象層
雖然 OSI 模型的每一個抽象層都有助于整個網絡的互操作性, 但每個抽象層都是弗吉尼亞建模分析和模擬中心（VMASC）定義的互操作性模型(LCIM)[2]中的三類互操作性之一。 這就是技術互操作性、句法互操作性和語義互操作性[3] ：
- 技術互操作性是網絡交換任何形式原始信息的基本能力。 技術互操作性由 OSI 棧(層1-4)的較低層級管理, 這些層次定義了網絡上各點之間可靠傳輸和接收數據的基礎設施。
- 句法互操作性是在兩臺或多臺機器之間交換結構化數據的能力, 通常由 OSI 模型的第5層和第6層處理。 在這里, XML 和 JSON 等標準數據格式提供了語法, 使系統能夠識別正在傳輸或接收的數據類型。
- 語義互操作性使系統能夠以上下文的方式從結構化數據中解釋意義，并在 OSI 棧的第7層中實現。
在 OSI 框架中, 每個抽象層的正確實現都有助于實現互操作性, 技術上的互操作性使得句法互操作性得以實現, 進而又可以實現語義互操作性。 技術互操作性目前在多領域通信網絡中得到很好的理解和標準化, 這使得句法和語義層成為了真正可互操作的M2M數據通信的關鍵因素。
從句法到語義互操作性的轉變
在 OSI 模型的第1至第4層提供了一套基于協議的網絡基礎設施技術, 而句法和語義互操作性通常依賴于針對特定行業的格式和協議, 并根據現有的系統和數據類型進行優化。 這一事實導致了對現有網絡基礎設施進行了數十億美元的投資, 以支持在這些垂直市場上的 M2M 通信[4]。
為了在這些情況下促進廣泛的句法互操作性, 工業互聯網聯盟（IIC）最近發布了"工業互聯網連接框架"或 IICF [3]。 IICF 重新定義了傳統的 OSI 模型, 將表示層和會話層(第5層和第6層)結合起來, 提供所有必要的機制, 以便"促進數據如何由端點無歧義地結構化和解析"(圖2)。 跨行業領域的句法互操作性得到了一套"核心連接標準"(目前為數據分配服務(DDS)、 opc-unify 架構(OPC-UA) , oneM2M, 以及 web services) , 這些標準通過一套擬議的標準化網關進行通信。
圖2 | IIC的連接框架層為不同系統和領域的句法互操作性提供了基礎
IICF 框架層允許在不同服務質量(QoS)級別上在應用程序之間傳輸的狀態、事件和流。 這樣的架構足以滿足句法互操作性的要求。
除了 IICF 的句法互操作層之外, 還有信息層(OSI 模型中的應用層) , 這個層面的語義互操作性尚未確定。 在這里發生的分布式數據管理和互操作性依賴于兩臺或多臺機器之間的指定本體, 可以自動而準確地解釋交換數據的含義(上下文) , 并將其應用到一個有價值的目標。 正如 IICF 對于句法互操作性的方法所建議的, 本體必須考慮到在不同的系統和環境之間交換的元數據。 它代表了連接系統之間***級別的互操作性。
一些行業組織努力實施涵蓋盡可能廣泛的行業和系統的語義數據模型(信息模型)。 它們包括 Object Management Group (OMG)、 IPSO 聯盟、開放連接基金會(OCF)、開放組織、 zigbee、 Global Standards 1(GS1)、 Schema.org、 Project Haystack 等。 然而, 它們在實現適用于基礎廣泛的跨行業用例語義數據方案方面基本上沒有成功, 因為它們的經驗往往基于一系列狹窄的技術或行業細分。
下面描述了如何利用每種方法的***屬性來實現跨多個行業和環境的可伸縮語義互操作性。
描述數據-數據語義的含義
從傳感器到執行器的數據
物聯網正在改變我們的世界, 影響著我們管理和操作環境的方式, 比如家庭、建筑、商店、醫院、工廠和城市。 低成本的傳感器, 更強大的控制器, 云服務, 智能設備和新的軟件應用使得從設備到供應鏈的一切事物都得到了新的管理。
智能設備正在大幅增加從環境中獲得數據的數量和類型, 而新型的軟件應用程序正在創造新的方式從這些數據中獲益。 這些進展共同推動了我們如何管理和操作這些環境的根本性轉變, 使我們能夠從基于簡單反饋回路的傳統控制戰略轉變為以數據為導向的方法, 使締約方能夠實時了解智能設備和系統的實際運行情況。
所有這些趨勢都有助于提高效率, 并在有效使用的情況下, 推動整體業務成本的節省。 然而, 獲取數據是一回事, 讓數據具有可操作性是另一回事。 由于現有的數據比以往任何時候都多, 因此產業面臨著新的挑戰。
毫無疑問, 物聯網和自動化系統的廣泛應用所面臨的***障礙是互操作性。 麥肯錫公司的一份報告中估算, 實現物聯網的互操作性將會為總的可用市場中增加40% 的額外價值。
智能設備的數據以多種不同的格式存儲和傳遞。 它有不一致的、非標準的命名約定, 并提供非常有限的描述符用于理解其含義。 簡單地說, 智能設備和自動化系統的數據缺乏信息來描述它自己的意思。 如果沒有意義, 就需要進行耗時的規范化努力, 才能有效地利用數據來產生價值。 現狀是, 當今設備的數據雖然在技術上是"可用的", 但卻難以使用, 從而限制了締約方充分受益于數據[5]中所承載的價值。
為了充分利用分析應用、遠程設備管理和自動化系統等程序中的數據, 我們需要知道數據的含義。 例如, 如果從智能建筑系統中的傳感器點獲得數據, 它可能包含一個值為77.6。
[圖3 | 示例傳感器值]
首先，在理解值的數據類型之前, 我們不能做任何有效的分析或處理。 這個值是否代表溫度、速度、壓力或其他數據類型？
[圖4 | 數據類型語義的示例值]
如果這個值代表一個溫度, 那么我們需要知道它是77.6華氏度還是攝氏度呢？ 度量單位是我們理解和使用數據所需要的另一個基本描述符。
[圖5 | 單元語義的示例值]
繼續這個例子, 如果只知道數據類型(溫度)和測量單位(華氏度) , 我們仍然不太了解這個值的重要性。 溫度值是否代表空氣、水或其他環境條件？
如果是建筑物某一樓層的空氣溫度, 對于住戶來說可能有點熱。 如果是鍋爐的水溫, 那就太涼了。
[圖6 | 對象語義的示例值]
***, 如果價值代表一個建筑物內部某層的一個空氣溫度, 那么當建筑是空置的時候, 它可能是很好的, 但是當它被使用的時候可能就不是這樣了。 所以事件的日期和時間也很重要。
[圖7 | 示例值與時間戳]
讓我們假設值為77.6的傳感器由名稱(即標識符)"zn3-wwfl4"來識別。 如果我對安裝時使用的建筑系統和命名約定非常熟悉, 我也許能夠確定這意味著西翼第3區, 第4層等這些信息來解決問題。如果我對這座建筑了如指掌, 我也許還能看出,"zn3-wwfl4"標識符是按照第1號占用調度時間表(上午7時30分至下午6時30分)運作的樓層空氣溫度。
有了這些額外的信息, 可以確定一個工作日上午9點的值為77.6是不合適的, 因為天氣太熱, 會導致乘客投訴。 然而, 使我能夠作出這一決定的是有關特定傳感器含義的大量信息。 我之所以碰巧掌握這些信息, 是因為我個人對建筑物的了解, 但是在控制系統(或任何一個數據存儲器中沒有記錄到的信息) 中, 可能不能夠以任何一致的"機器可讀"格式提供。
這就是利用現有系統和設備產生豐富數據的挑戰——數據的表示、交流和解釋能力。 這種"關于數據的數據表示"通常被稱為元數據或數據語義。
有關傳感器點的適當元數據將使我們能夠了解目前77.6的價值所產生的影響, 而不需要依靠個人對系統的了解。 如上所述, 如果我們知道與傳感器相關位置的相關時間, 我們就可以確定它在被占用的時間段溫度過高, 而且用戶很可能會感到不舒服。
然而, 如果沒有必要的元數據, 我們無法確定當前值的影響及其與相關運行系統的關系。因此, 為了有效地使用數據, 我們需要將元數據和傳感器值結合起來。 當人工完成時, 這個過程被稱為映射或數據規范化。對于如數據分析、遠程設備管理和自動化系統這些新實施的軟件應用程序，時間序列數據處理是一個耗費時間的過程。
有趣的是, 在過去的十年里, 標準的通信協議幾乎沒有為大多數自動化系統提供任何能力來捕捉他們所包含數據的語義信息。 沒有一種標準化的方法來表達它們所產生或包含的數據含義。 該系統提供帶有標識符的傳感器點(zn3-wwfl4) , 一個值(77.6)和單位(華氏度) , 但是其他信息很少。 結果是需要一個勞動密集的過程來"映射"數據(數據映射) , 然后才能開始有效使用傳感器數據。 顯然, 這對有效使用智能設備中的數據造成了重大障礙。
[圖8 | 數據交換和規范化]
分析人士預測, 到2020年, 物聯網將有超過250億個連接設備。 總之, 這些設備將產生***的數據量, 為了創造價值, 必須有效地索引、共享、存儲、查詢和分析。
越來越多的數據被規范化為時間序列數據——標有時間戳的數據——并以定期(基于間隔)或狀態(或值)更改(基于事件)進行傳輸。
[圖9 | 時間序列和事件]
雖然應用分析程序只需要時間序列數據的單向流動, 但自動化系統需要雙向數據流, 以便將測量數據從傳感器和指令消息傳遞給執行器。
[圖10 | 雙向數據流]
元數據挑戰
那么我們如何獲取所有這些信息, 分享它, 并將它與我們的自動化系統和智能設備中的數據元素聯系起來呢？ 不能僅僅通過使用標準化的點標識符來做到這一點。 即使在這個的簡單例子中, 我們有更多的元數據才能有效地捕捉到一個點標識符。 除此之外, 我們可能希望隨著時間推移增加許多其他數據元素, 這遠遠超出了這個簡單的例子, 顯然我們需要另一種方法。 有效的解決辦法必須具有以下特點:
點標識符與相關元數據的解耦合。事實上, 我們有成千上萬個系統中的數百萬個點和它們的點標識符且無法改變。我們需要的是一個標準化的模型來聯系點標識符和元數據。
應該利用一個點標識符元數據的標準化庫來提供元數據的一致性。這將使軟件應用程序能夠解釋數據意義, 而不需要數據的規范化。隨著新應用的涌現, 標準庫需要由行業組織維護，使元數據具有良好的擴展性。
跨行業領域的用例
語義互操作性面臨的一個關鍵挑戰是, 能否在不同行業領域之間實現互操作性, 每個行業都有自己的環境和互操作性的應用場景。 在本系列接下來的部分中, 討論了五個相互關聯的行業——住宅與建筑、能源、零售、醫療和運輸及物流。
[圖11 | 工業用例受益于語義互操作性]
References:
“Oxford Dictionaries – Dictionary, Thesaurus, & Grammar.” Oxford Dictionaries | English. Accessed June 20, 2017. https://en.oxforddictionaries.com/.
Andreas, T., et al. “Applying the Levels of Conceptual Interoperability Model in Support of Integratability, Interoperability, and Composability for System-of-Systems Engineering.” Virginia Modeling Analyses & Simulation Center, Old Dominion University. Accessed June 20, 2017. http://www.iiisci.org/journal/cv$/sci/pdfs/p468106.pdf
“The Industrial Internet of Things Volume G5: Connectivity …” Accessed June 20, 2017. https://www.iiconsortium.org/pdf/IICPUBG5V1.0PB_20170228.pdf
ReportsnReports. “M2M, IoT & Wearable Technology Market – 30% CAGR for Installed Base Connections by 2020.” PR Newswire: news distribution, targeting and monitoring. June 21, 2016. Accessed June 20, 2017. http://www.prnewswire.com/news-releases/m2m-iot–wearable-technology-market—30-cagr-for-installed-base-connections-by-2020-583815741.html.
Petze, John. “Describing the Meaning of Data—An Introduction to Data Semantics and Tagging”, Project Haystack Connections, Issue 1, Spring 2016.
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
