這個由多部分組成的系列解決了對支持物聯網 （IoT） 以及建筑物、企業和消費者的數字化轉型的單一語義數據模型的需求。這樣的模型必須簡單且可擴展，以實現即插即用互操作性和跨行業的普遍采用。

物聯網網絡抽象層和互操作性程度

互操作性，或計算機系統或軟件交換或利用信息的能力，是參與當今信息經濟的所有設備的要求。傳統上，互操作性主要是在網絡通信的背景下定義的。但是，隨著從智能家居和樓宇自動化到智能能源和零售再到醫療保健和交通運輸等行業的數百萬設備連接在一起，現在需要一個更廣泛的定義，以考慮互操作性對系統到系統性能的跨域影響。

開放系統互連 （OSI） 模型提供了定義網絡互操作性框架的最著名示例，它是全球電信網絡的基礎。OSI 模型通過七個不同的抽象層提供互操作性框架，這些抽象層隔離和定義各種通信功能，從物理媒體中的比特傳輸（第 1 層）到在軟件中共享應用程序數據（第 7 層）。這些層的簡要描述及其用途可以在圖 1 中找到。

【圖1 | OSI 模型概述了促進電信和計算網絡互操作性的七個抽象層。］

雖然 OSI 模型的每個抽象層都有助于整體網絡互操作性，但每個抽象層都通過解決弗吉尼亞建模分析和模擬中心的概念互操作性模型 （LCIM）［2］ 級別定義的三類互操作性之一來實現這一點。這三類分別是技術互操作性、句法互操作性和語義互操作性［3］：

技術互操作性是網絡交換任何類型的原始信息的基本能力。技術互操作性由較低級別的 OSI 堆棧（第 1 - 4 層）管理，這些堆棧定義了在網絡上的點之間可靠地傳輸和接收數據的基礎設施。

句法互操作性，或在兩臺或多臺機器之間交換結構化數據的能力，通常由 OSI 模型的第 5 層和第 6 層處理。在這里，XML 和 JSON 等標準數據格式提供了允許系統識別正在傳輸或接收的數據類型的語法。

語義互操作性使系統能夠以上下文方式（通常通過使用元數據）解釋結構化數據的含義，并在 OSI 堆棧的第 7 層中實現。

在 OSI 框架中，每個抽象層的正確實現有助于形成互操作性瀑布，技術互操作性支持句法互操作性，進而實現語義互操作性。技術互操作性目前在多域通信網絡中得到很好的理解和標準化，將句法和語義層作為真正可互操作的機器對機器 （M2M） 數據通信的關鍵可尋址點。

從句法互操作性到語義互操作性的轉變

OSI 模型的第 1 層到第 4 層提供了一套不可知的基于 Internet 協議 （IP） 的網絡基礎設施技術，句法和語義互操作性通常依賴于基于系統和數據類型優化的行業特定格式和協議。手。為支持這些垂直市場中的 M2M 通信而對現有網絡基礎設施進行了數十億美元的投資，這一事實變得更加復雜［4］。

為了在這些情況下促進廣泛的句法互操作性，工業互聯網聯盟 （IIC）最近發布了“工業互聯網連接框架”或 IICF［3］。IICF 通過組合表示層和會話層（第 5 層和第 6 層）重新定義了傳統的 OSI 模型，以提供所有必要的機制來“促進端點如何明確地結構化和解析數據”（圖 2）。一組“核心連接標準”（目前是數據分發服務 （DDS）、OPC 統一架構 （OPC-UA）、oneM2M 和 Web 服務）支持跨行業句法互操作性，這些標準通過一組建議的標準化進行通信網關。

【圖2 | 工業互聯網聯盟的連接框架層為跨不同系統和域的句法互操作性提供了基礎。］

IICF 框架層允許在不同的服務質量 （QoS） 級別的應用程序之間傳輸狀態、事件和流。這樣的架構足以滿足句法互操作性的要求。

除了 IICF 的句法互操作層之外，還有信息層（OSI 模型中的應用層），其中語義互操作性尚未指定。這里發生的分布式數據管理和互操作性依賴于兩臺或多臺機器之間的指定本體，以自動準確地解釋交換數據的含義（上下文）并將其應用于有價值的目的。正如 IICF 的句法互操作方法所建議的那樣，該本體必須考慮在不同系統和環境之間交換的元數據 。它代表了連接系統之間最高級別的互操作性。

一些行業組織已努力實施涵蓋盡可能廣泛的行業和系統的語義數據模型（信息模型）。這些聯盟包括對象管理組 （OMG）、IPSO 聯盟、開放連接基金會 （OCF）、開放組、zigbee、全球標準 1 （GS1）、Schema.org、Project Haystack， 和別的。然而，他們在實現適用于基礎廣泛的跨行業用例的語義數據方案方面在很大程度上沒有成功，因為他們的經驗往往基于狹窄的技術或行業細分集。

以下文章系列介紹了如何利用每種方法的最佳屬性來實現跨多個行業和 環境的可擴展語義互操作性。

描述數據的含義——數據語義

從傳感器到執行器的數據

物聯網 （IoT） 正在改變我們的世界，影響著我們管理和運營家庭、建筑物、商店、醫院、工廠和城市等環境的方式。成本更低的傳感器、更強大的控制器、“云”、智能設備和新的軟件應用程序正在實現管理從設施到供應鏈的一切的新方法。

智能設備正在顯著增加我們環境中可用數據的數量和類型，而新的軟件應用程序正在創造從這些數據中受益的新方法。這些進步共同推動了我們管理和操作這些環境的方式發生根本性轉變，使我們能夠從基于簡單反饋回路的傳統控制策略轉變為實時告知各方智能設備和系統的實際性能的。

所有這些趨勢在有效結合使用時都有助于提高效率并節省總體運營成本。但是，訪問數據是一回事。使其具有可操作性是另一回事。隨著可用數據比以往任何時候都多，行業面臨著新的挑戰。

毫無疑問，廣泛采用物聯網和自動化系統面臨的最大障礙是互操作性。麥肯錫的一份報告估計，在物聯網中實現互操作性將在整個可用市場中增加 40% 的價值。

來自智能設備的數據以多種不同的格式進行存儲和通信。它具有不一致的、非標準的命名約定，并提供非常有限的描述符以使我們能夠理解其含義。簡而言之，來自智能設備和自動化系統的數據缺乏描述其自身含義的信息。在沒有意義的情況下，需要進行耗時的標準化工作，然后才能有效地使用數據來產生價值。結果是來自當今設備的數據雖然在技術上“可用”，但很難使用，從而限制了各方從數據中包含的價值中充分受益的能力。

為了在分析、遠程設備管理和自動化系統等增值應用程序中利用數據，我們需要了解數據的含義。例如，如果我們從樓宇自動化系統（BAS） 中的傳感器 點獲取數據，它可能包含 77.6 的值。

【圖3 | 示例傳感器值］

在我們首先了解值的數據類型之前，我們無法進行任何有效的分析或處理。該值是否代表溫度、速度、壓力或其他一些數據類型？

【圖4 | 具有數據類型語義的示例值］

如果該值代表一個溫度，那么我們需要知道它是 77.6 華氏度還是攝氏度。度量單位是我們理解和使用數據所需的另一個基本描述符。

【圖5 | 具有單位語義的示例值］

繼續我們的示例，如果我們只知道數據類型（溫度）和測量單位（oF），我們仍然不太了解值 77.6 的重要性。溫度值是否代表空氣、水或其他一些環境條件？

如果是建筑物內樓層的空氣溫度，則對居住者來說可能有點熱。如果是鍋爐的水溫，可能太涼了。

【圖6 | 具有對象語義的示例值］

最后，如果 value 表示建筑物內樓層的空氣溫度，則建筑物無人使用時可能很好，但有人占用時則不然。所以活動的日期和時間也很重要。

【圖7 | 帶時間戳的示例值］

假設值為 77.6 的傳感器由名稱（即標識符）“zn3-wwfl4”標識。如果我非常熟悉建筑系統和安裝時使用的命名約定，我可能能夠確定這意味著 3 區，西翼，4 樓。這會給我一些信息來處理。如果我對建筑物很了解，我可能還可以判斷出標識符“zn3-wwfl4”是按占用計劃 #1（上午 7 點 30 分至下午 6 點 30 分）運行的樓層的空氣溫度，并且具有占用的冷卻設定點為 74 oF。

有了這些附加信息，我可以確定 77.6 的值不適合工作日上午 9:00 ——它太熱了，會導致乘客抱怨。然而，使我能夠做出決定的是關于特定傳感器含義的大量信息。由于我對建筑物的個人了解，我碰巧擁有的信息——但信息未記錄在控制系統（或任何單個數據存儲）中，并且不以任何一致的“機器可讀”格式提供。

這是使用當今系統和設備產生的大量數據所面臨的挑戰——表示、交流和解釋數據含義的能力。這種“關于數據的數據”通常被稱為元數據或數據語義。

擁有有關傳感器點的適當元數據將使我們能夠了解當前值 77.6 的影響，而無需依賴個人對系統的了解。如上所述，如果我們知道與傳感器關聯的位置相關的時間表，我們可以確定它在占用時間內溫度過高，并且居住者很可能不舒服。

但是，如果沒有必要的元數據，我們就無法確定當前值的影響及其與正常系統操作的關系。因此，為了提供數據的有效使用，我們需要將元數據與傳感器 值結合起來。手動完成時，此過程稱為映射或數據規范化。歷史上，利用時間序列數據的這一步驟一直是一個耗時的手動過程，這大大增加了新軟件應用程序（如分析、遠程設備管理和自動化系統）的實施成本。

有趣的是，憑借過去十年獲得的所有功能以及標準通信協議的采用，大多數自動化系統幾乎沒有能力捕獲有關其包含的數據的語義信息。沒有標準化的方法來表示它們生成或包含的數據的含義。系統為傳感器點提供標識符（ zn3 -wwfl4）、值（77.6） 和單位（oF），但幾乎沒有其他信息。結果是，在有效使用傳感器之前，需要一個勞動密集型過程來“映射”數據（數據映射） 數據可以開始了。顯然，這對有效使用智能設備提供的數據造成了重大障礙。

【圖8 | 數據交換和規范化］

到 2020 年，物聯網中的連接設備將超過 250 億臺。這些設備一起將產生前所未有的海量數據，為了創造價值，必須對這些數據進行高效索引、共享、存儲、查詢和分析。

越來越多地，這些數據被規范化為時間序列數據——標記有時間戳的數據——并以定期間隔（基于間隔）或狀態（或值）更改（基于事件）傳輸。

【圖9 | 時間序列和事件］

雖然分析應用程序只需要時間序列數據的單向流，但自動化系統需要雙向數據流來將測量數據從傳感器和命令消息傳輸到執行器。

【圖10 | 雙向數據流］

元數據挑戰

那么我們如何才能捕獲所有這些信息，共享它，并將其與我們的自動化系統和智能設備中的數據元素相關聯呢？我們不能簡單地嘗試使用標準化的點標識符來做到這一點。即使在我們的簡單示例中，我們的元數據也比在點標識符中有效捕獲的要多。除此之外，隨著時間的推移，我們可能希望添加許多其他數據元素，這些數據元素遠遠超出了我們的簡單示例，顯然我們需要另一種方法。一個有效的解決方案需要具備以下特點：

它應該將點 標識符與相關元數據的表示分離。現實情況是，我們在數千個系統中擁有數百萬個點，并且它們的點 標識符無法更改。這根本不是一種選擇——也沒有必要。需要一個標準化模型來將元數據與現有的點標識符相關聯。

它應該利用標準化的元數據 標識符庫來提供元數據術語的一致性。這將使軟件應用程序無需規范化即可解釋數據含義。隨著新應用程序的引入，該庫需要由行業專家維護。因此，元數據方法需要可擴展。

跨行業用例

語義互操作性的一個關鍵挑戰是能夠跨不同行業實現互操作性，每個行業都有自己的環境和互操作性用例。在本系列的后續部分中，將討論五個相互關聯的行業——住宅和建筑、能源、零售、醫療保健以及運輸和物流。

審核編輯：郭婷